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EXECUTIVE SUMMARY 


This docunent presents some basic tenets of safety as applied to develop- 
mental aircraft programs. It does not discuss the philosophy of system 
safety nor does it present instructions for applying system safety prin- 
ciples to a project. Rather, the integration of safety into the project 
management aspects of planning, organizing, directing, and controlling is 
ill unrated by examples. The examples presented here are taken from the 
joint NASA/ Army Rotor System Research Aircraft (RSRA) project which has 
maintained an enviable safety record through several years of development 
and operation. 

The RSRA project was initiated in 1973 to produce vehicles for conducting 
advanced rotor systems research. The project resulted in production of two 
highly instrumented aircraft capable of flying in the fixed-wing, helicopter 
or compound modes. The specifications established a performance envelope 
that exceeded normal helicopter performance in many ways while stressing 
adaptability to new rotor systems, precisely controlled test conditions, and 
measurement accuracy. Fulfillment of these specifications required advance- 
ment of state-of-the-art technology in many areas, such as provision for 
crew escape in an emergency. It also required close coordination between 
NASA and contractor personnel. This, in turn, necessitated formulation of 
unusual communication protocols which fostered development of a “project 
family" attitude. 

The RSRA project office was originally based at Langley Research Center and 
operated within the confines of a typically austere research and development 
budget. During later stages of development the project was transferred to 
the Pmes Research Center resulting in general loss of corporate memory and 
necessitating changes in the system safety program to compensate for this 
loss. 

To begin an overview of the RSRA safety program, it would be well to under- 
stand the attitude and philosophy of the former RSRA Project Manager/Chief 
Engineer, Sam White, Jr. His approach to safety on the project was guided 
by the following philosophy: 

“The system safety program that evolved on the RSRA was based on a set of 
concepts, some basic system safety principles, and on a fairly limited set 
of guidance documents. A list of some pretty basic (yet very useful) 
principles was used in developing the RSRA system safety program (courtesy 
of Chuck Miller's George Washington University program on aviation safety): 

a. Accidents are unplanned, but controllable combinations of events. 

b. Accidents are rare; hazards (risks) are not. 

c. Combinations of "acceptable" hazards produce accidents. 

d. Accidents are usually caused by a sequence of complex cause-effect 
relationships that may be obscured by simplistic probabl e/ proximate cause 
determ inati ons. 
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e. Cause- prevent ion determination should include factors of: 

- Man (human error, workload). 

- Machine (failure, design defect). 

- Medium (environment) . 

- Management (attitude, motivation, control). 

- Mission (nature, urgency). 

- Money (cost/ safety tradeoffs). 

f. Safety is an integral part of mission accomplishment (economic, 
survival) . 

g. Accident prevention is more than accident investigation and cause- 
corrective action determination. 

h. Managers/supervisors can del eg ate/ assign safety authority/ actions 
but cannot delegate accountability. 

i. A data bank of known precedents exists for risks and corrective 
acti ons . 

j. Hazard/ accident reporting must emphasize corrective action, 
including rule enforcement, without seeking to punish improper action. 

k. Human hyperawareness of high risk often results in a higher level 
of safety. 

l. Safety tasks are finite, identifiable, definable, and do-able. 
Competently done, they reduce accidents. 

- Define requirements (process and results, not procedures: What, 

not how ) , 

- Prepare plans (road map, who/what/when) . 

- Conduct hazard analyses. 

- Develop emergency as well as normal procedures. 

- Conduct program reviews (use jury approach). 

- Influence behavior (educate, train, indoctrinate, motivate, 
correct) . 

- Conduct surveys, audits, inspections. 

- Use known precedent centers. 

- Investigate accidents/incidents (determine cause, take corrective 
action, follow-up). 

- Provide staff "Chaplain," ombudsman (opens free communication, 
emphasizes correction, deemphasizes punishment, provides 
1 iaison) . 

The list of safety tasks under the last bullet is particularly useful in 
planning a system safety program." 

The applications of these and the other basic principles are illustrated in 
detail throughout the text. 
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The methods by which safety would be achieved were documented in an Air- 
worthiness Qualification Plan (AQP) developed early in the project. The 
requirements specified by the AQP were carefully tailored to fit the speci- 
fic RSRA mission objectives and to satisfy the intent of agency criteria. 

The RSRA project budget did not permit a large safety cadre. Therefore, a 
safety focal point was established and the entire project staff became 
involved in the attainment of safety objectives. Safety goals became pro- 
ject goals and increased safety consciousness of the staff resulted. 
Resource allocations were altered when necessary to provide for performance 
of safety tasks of most benefit. This "horse-trading" of resources involved 
some risk which project management accepted when necessary, but as a con- 
scious act, not through ignorance or default. This bold stance was justi- 
fied because management remained deeply involved in safety activities 
throughout project development. 

In the final synopsis of RSRA safety experience, it should be noted that 
safety goals were given in terms of positive actions. That is, negative 
connotations were avoided with reference to safety, and attitudes were 
fostered to keep safety in concert with other project activities. 

It was recognized early in the project that even ul tra- attention to safety 
in the design and ground test phases would not assure operational safety without 
in-depth knowledge and awareness by the flight team. For this reason, both 
Government and contractor fl ightcrews were involved throughout the design, 
development, test and evaluation (DDT&E) process. 

While the RSRA experience was not a perfect example of "doing everything 
right," it came close. Some painful lessons were learned, especially rela- 
tive to safety impacts of schedule slippages, transfers of roles and 
missions, and associated loss of corporate memory. However, flexibility was 
found to be a key. When events beyond project management control led to 
schedule impacts, slippage was allowed, but not loss of project control. 

In the words of the RSRA Chief Engineer, "The fact that the project matured 
effectively and without incident is believed to be a direct result of the 
breadth and depth of safety planning and the in-depth involvement of all 
hands in safety plan implementation. The point is that the energies devoted 
to safety tasks are not all penal ti es to be suffered out of the need for 
safety; they produce benefits that enhance operational efficiencies, safety 
aside." 
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1.0 INTRODUCTION. This document explores those aspects of project activi- 
ties required to facilitate development and implementation of a safety plan 
and practices which fit aircraft development or modification projects. 
Properly tailored, safety tasks are finite, identifiable, definable, and 
do-able. Competently done, they reduce accidents and make significant cost 
and performance effective contributions to the project. 

The guidance provided in this document for tailoring a safety program uses 
the experience gained from the NASA/ Army Rotor Systems Research Aircraft 
(RSRA) project. The RSRA project planning, organizing, directing, and 
controlling activities enabled the identification of safety requirements and 
tools and implementation of a plan which met the unique needs of the 
proj ect . 

The RSRA experience was selected as a model for a number of reasons: Safety 

was an integral part of the project; the project was current (development 
and start of operation spanned the middle 1970 's to early 1980); both evolu- 
tionary and revolutionary state-of-the-art techniques were used; an austere, 
cost-conscious environment prevailed; a high degree of tailoring in terms of 
airworthiness and safety standards was required; the system safety program, 
as implemented, provided integration and synergism with the ongoing project; 
and no accidents or safety incidents had occurred in 3 1/2 years of 
operation. 

The need for a rotor system test bed was recognized by both the Army and 
NASA in the 1960 ‘s. The establ isinent of a Directorate for the Army at 
several NASA Centers led to a combined NASA/ Army effort to develop the RSRA 
through the normal process of concept studies, predesign studies, and 
finally a contract to build the aircraft in November 1973. The conceptual 
studies considered system safety, and a formal safety program was initiated 
when the specifications for the aircraft were established. 
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PRIMARY PURPOSE 


• EVALUATE ADVANCED ROTOR SYSTEMS 

• VERIFY NEW ROTORCRAFT TECHNOLOGY 


KEY CHARACTERISTICS 


• TWO VEHICLES 

• COMPOUND FLIGHT MODES 

• COMPUTER CONTROLLED FBW SYSTEM 

• IN-FLIGHT MEASUREMENT OF ROTOR 
STATE AND LOAD 

• VNIQUE VIBRATION CONTROL SYSTEM 

• PYROTECHNIC ESCAPE SYSTEM 


Figure 1.0-1 Rotor Systems Research Aircraft (Ames Research Center) 







The RSRA project was initiated in 1973 to develop two research aircraft for 
evaluating advanced rotor systems and conducting rotorcraft flight research 
in a capable, efficient and cost-effective manner. The aircraft, shown in 
Figure 1.0-1, is a sophisticated test bed capable of flying as a helicopter, 
fixed-wing aircraft or combination thereof. It possesses systems and capa- 
bilities unique in the world of aviation, as illustrated in Figure 1.0-2. 
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Figure 1.0-2 RSRA Systems and Capabilities 


To provide an appreciation for the complexity of some of the safety issues 
that will be discussed, a detailed explanation of several of the unique 
safety systems of the RSRA is necessary. 

a. Emergency Escape System (EES): Although escape systems are common 

on nonpassenger fixed-wing aircraft, no helicopter had ever been equipped 
with such a system. The auxiliary engines and the wing present obstacles to 
emergency escape "over-the-side" crew egress (Figure 1.0-3). 
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SEVERED/FRACTURED 



Figure 1.0-3 RSRA Crew Escape System 


An EES is requi red to provide safe crew egress in an emergency such 
as fire, loss of control, or structural failure of a research rotor. The 
system provides for pyrotechnically severing the rotor blades, jettisoning 
and fracturing the canopies and extracting the crew members via tractor 
rockets. The blade severance system indexes the blades off sequentially in 
safe paths that avoid the aircraft and its flight path. The extraction 
system extracts crewmembers in a time sequence and trajectory path that 
provides separation from each other as well as from the aircraft structure. 
A static line extracts the parachute deployment bag, separates the crew- 
member from the seat back and initiates chute deployment. The system was 
qualified by a series of full-up sled tests and component tests. 
Transposing sled test data (with the sled constrained to the test track! to 
free maneuvering flight regimes was done by analysis. The resulting escape 
envelope covered zero/zero (zero altitude, zero airspeed) up to a modest 
cruise speed vhich was less than the maximum operational speed of the air- 
craft. The speed restriction resulted from a risk of entanglement of the 
deployment bag on aircraft structure in some combinations of aircraft 
attitude and postinitiation maneuvers. 

b. Main Rotor Load Measurement System: A " six- component" wind tunnel 

type load cell balance system, as shown in Figure 1.0-4, is installed 
between the rotor and the airframe to provide a precise measure of the three 
forces and three moments imposed by the rotor on the airframe. 
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SLOPfV LINKS PAIRED 
WITH LOAD CELLS 
PROVIDE ALT LOAD 
PATHS IN-PLANE C Q 


FAIL SAFE 
STRUCTURALLY 

redundant 

VERTICALLY 
(A, B, C e D) 


Figure 1.0-4 Main Rotor Load Measurement System 


In actual implementation, a tradeoff is required between accuracy 
and structural integrity. For maximum accuracy and sensitivity, the load 
cells should be as thin as possible and there should be six load cells to 
fully define a statically determinant system. For maximum structural 
integrity, the members should be as "beefy" as possible and should be 
multiple redundant (such as by means of a 32-bolt circle attachment). The 
compromise was to provide redundancy via four vertical members, any three of 
which could carry design limit loads. Redundancy in the "in-plane" (lateral 
and fore & aft) direction was provided by "sloppy link" alternate load paths 
that pick up load when the system deflects a given amount on failure of any 
one load cell. 

c. Active Isolation and Balance System (AIBS): An alternative main 

rotor load measurement system. Figure 1.0-5, is provided that not only 
measures loads but also isolates the airframe from "higher" frequency (3 to 
30 Hz) rotor-induced vibratory forces. 



Figure 1.0-5 Schematic of Current AIBS Design 
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structural integrity compromises were made to measurement system 
accuracy, similar to those made for the load cell system. The high 
vibratory force content of some of the candidate research rotors is such 
that vibration isolation is mandatory. When testing those rotors, the A IBS 
configuration would be used. In those cases, the first failure of the 
system had to be not only "fail-safe" (i.e. structurally adequate) but also 
"fail -operable" (i.e., continue to isolate high vibratory loads); thus, the 
need for the "auxiliary" isolator unit shown in Figure 1.0-5. As shown in 
Figure 1.0-6 the active isolator is effective in providing a 10:1 reduction 
in response to peak vibration modes at about 12 to 16 Hz. 



Figure 1.0-6 Isolator Effectiveness 

d. Flight (kintrol System: Two primary flight control systems are 

provided, with an additional onboard computer controlled Electronic Flight 
Control System (EFCS) and a Stability Augmentation System (SAS) as shown in 
Figure 1.0-7. The Safety Pilot's system is a relatively conventional hydro- 
mechanical boosted system; however, it is unique in that it provides actua- 
tion of both the fixed-wing airplane control surfaces (elevator, aileron, 
rudder) and the rotor swashplate controls. The control motions are split at 
a "Control Phasing Unit," which apportions motions to the fixed-wing and 
rotor controls in a pilot selectable schedule (i.e., 100 percent to both, 
100 percent to one and 0 percent to the other, or any continuous combination 
of these). The Evaluation Pilot's controls are a "fly-by-wire" electrical 
tie-in to the Safety Pilot's hydromechanical controls through the Force 
Feel System. Both the EFCS and the SAS provide limited authority inputs to 
the flight controls, independent of any pi lot- initiated conmands. 
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Figure 1.0-7 RSRA Flight Control System 




This document presents the basis for project management use of safety and relates 
these management functions to "real-world" situations encountered on the RSRA 
project. In each example both the rationale which led to the safety- rel at ed 
project decision and the lessons learned as they may apply to future projects are 
presented. 
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2.0 PLANNING . The bases for RSRA project safety planning were: 

a. Establishing the methods by which basic program risks could be 
identified. 

b. Defining safety goals in terms of overall RSRA project goals. 

c. Formulating specific project safety requi rements . 

d. Developing a detailed plan as an implementation guide for safety 
activities during product evolution. 

2.1 RECOGNIZING PROJECT RISKS. The RSRA project management actively sought 

to identify and resolve project risks while recognizing both their moral and 
legal responsibilities. The moral responsibilities involved trust, image, 
reputation and the human desire to avoid injury to others. Legal responsi- 
bilities were perhaps more exacting. The potential consequences of failing 
to meet legal responsibilities were addressed by the RSRA project manager in 
briefings to the Langley Aviation Safety Committee. Questions were 

straightforward; e.g., "How would you, in your current role in this project, 

respond at an accident review board or in a court of law?" The legal issues 
involve the "feasances"; that is, in the event of an accident, penalties up 
to and including imprisonment may be levied upon conviction of negligence. 
Negligence typically involves malfeasance, wherein it is judged that prob- 
lems, concerns, etc., were identified, but were ignored, and implementation 

of protective measures was deliberately avoided. Courts have been more 
lenient with respect to misfeasance cases wherein a hazard is identified and 
action is taken, or "reasonable" rationale for ass lining the risk is provided 
within current technology. Thereafter, if an accident results, the effec- 
tiveness and reasonableness of actions and rationale may be questioned. 
Nonfeasance arises from the total lack of safety studies to identify hazards 

and subsequently to eliminate or control those hazards. Courts typically 

deal severely with such dereliction of duty. 

Errors, failures, and unforeseen conditions do arise. Murphy lives; some 
even say he was an optimist. As potential undesired conditions are identi- 
fied, additional concerns are normally revealed. Because of the likelihood 
of such a "domino" effect, project drivers were identified and addressed 
early, as illustrated by the following issues which are paraphrased from a 
memorandum written by the contractor project manager at the initiation of 
the project: 

a. An escape system had never before been employed on a helicopter; 
however, because of the R&D nature of this project, such a provision was 
considered necessary. 

b. An active isolation and balance system (AIBS) was necessary to 
isolate rotor vibrations from the fuselage. This system had only been 
demonstrated in one axis, and not in flight. The need for further testing 
and analyses was indicated. 
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c. Measurement accuracy requirements for the onboard research instru- 
mentation (OBRI) were extremely tight. Operational data requirements and 
safety implementation called for the development and application of state- 
of-the-art instrumentation techniques. 

d. The EFCS, v#iich provided for a computer- control led flight capa- 
bility with a fly-by -wire backup system, was extremely complex. 

e. Efficient technical interchange required close coordination between 
NASA and contractor project teams. The contractor, however, was concerned 
that this coordination might be uncomfortably close. On the other hand, 
NASA needed to be aware of technical progress as well as maintain surveil- 
lance over contractor activities in terms of schedules and contract 
resources. These conditions required formulation of communication protocols 
by NASA and contractor management. 

Hardware, operational, and organizational issues were either directly or 
indirectly addressed in identifying potential project problem areas. This 
focused attention on critical issues early, thereby providing latitude in 
resolution concepts considered. Costly rework was minimized. Failure to do 
this early could cause compression of solution time, thus leaving designers 
"boxed in" as a result of firm designs in other areas. An important lesson 
learned is that early program-level risk identification is critical to 
system performance, cost, and schedule. 

Resolution methods or acceptance rationale for identified risks on the RSRA 
project resulted from consideration of the three factors illustrated by the 
triangle concept. Real-world problems dictated tradeoffs between the fac- 
tors shown in Figure 2.1-1, but a mutually acceptable balance was always 
maintained. 

SAFETY 


Figure 2.1-1 Typical Project Tradeoffs 



Virtually every project decision impacted performance and resources, and 
frequently safety. Figure 2.1-2 is an example of NASA direction to reduce 
cost consistent with the required degree of safety. Safety analyses pro- 
vided the management visibility to trade on the basis of knowledge. 
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Figure 2,1-2 


RSRA Cost Trade Example 


2.2 SETTING PROJECT GOALS. Armed with an insight into safety risks and the 
necessity for a safety program, the next step was to create a plan to con- 
ncn! manage safety was based upon project goals. The basic 

RSRA project goals, shown in Figure 2.2-1, reflect the concept that safety 
goals were an integral , balanced part of project goals. Project goals were 
neither overshadowed by safety nor was safety ignored. 
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Figure 2.2-1 Priority Design Objectives - Presentation at Kickoff 
Meeting Reflected Integrated Safety Activity 


The fundamental RSRA goals were directed toward producing a technically 
sound, safe aircraft. Each project goal encompassed general safety consid- 
erations. 

a. Project goal: Provide an accurate measurement system to obtain 

experimental in-flight test data. 

Safety consideration: Ensure appropriate balance between con- 

flicting requirements for measurement system accuracy {high sensitivity; 
determinant) and structural integrity (high safety factors, implying lower 
sensitivity; redundancy, implying indeterminate structure). 

b. Project goal : Provide precise control of test conditions . 

Safety consideration: Ensure appropriate balance between precise 

control of test conditions (implying computer-controlled fly-by-wire system) 
and safety/reliability (implying inherent reliability of mechanical systems 
relative to electronic systems). 

c. Project goal: Provide enhanced net lift and thrust test envelopes . 

Safety consideration: Ensure that safety provisions were adequate 

for all test envelopes. 

d. Project goal : Provide a vehicle which was adaptable to various 

rotor selections and configurations. 
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Safety consideration: Ensure that safety provisions were adequate 

for an hardware adaptations. 

e. Project goal: Provide a performance envelope allowing operation 

over a wide speed and maneuverability range. 

Safety consideration. Provide for operating personnel and public 
safety in all normal and predictable contingency and/or emergency modes. 

These interdependent project and safety goals illustrate that safety is an 
integral part of mission accomplishment and also that mission/safety trade- 
offs are necessary. Early formulation of project and related safety goals 
sufficiently broad to encompass project activities is essential. If these 
early goals are too specific, however, tunnel vision may result. 

2.3 SELECTING SAFETY REQUIREMENTS. "Requirements" are defined as those 
discrete actions necessary to achieve project goals. The set of safety 
requirements, viewed as a whole, addresses administrative authority, organiza- 
tion, tasks and timing, and system capabil i ties/ 1 imitations. 

NHB 1700.1 (V3) states that "Safety goals and objectives should be estab- 
lished, and the type of system safety input that is to be furnished to the 
overall program should be determined .... It should be noted that these 
goals must be structured such that safety tasks can be selected that will 
accomplish the goals and when the tasks have been completed the results of 
the effort will clearly demonstrate that the goals have been met." 

The RSRA safety goals related safety success to project success. Safety 
goals were established to describe how much safety was required or how much 
risk was acceptable. 

The top level safety goals are shown below: 

a. Protect the public. 

b. Avoid project personnel accidents. 

c. Prevent economic catastrophe. 

d. Minimize operational problems. 

The need to protect the public from hazards associated with the RSRA was 
paramount. Safety goals associated with this concern required consideration 
of potential crash landing situations; falling debris (e.g., severed rotor 
blades), and collision with military, commercial, or private aircraft. 

Avoidance of project personnel accidents or injury involved consideration of 
hazards directly associated with the RSRA, its support equipment and its 
operation. The obvious RSRA project safety goal then was to identify and 
eliminate or control all potential causes for such hazards considering both 
mission and ground operations. 

The third top level safety goal , to prevent economic catastrophe, was aimed 
at such events as loss of an aircraft (half of a two-aircraft fleet). 
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destruction of high-value one-of-a-kind hardware, or occurrence of events 
reflecting unfavorably upon the developing Center or Agency which could 
result in loss of project funding. 

The fourth goal, to minimize operational problems, dealt with such issues as 
schedule compliance and mission availability. This goal was the least 
significant for the RSRA project because of the minimal emphasis required on 
mission availability, as discussed elsewhere. Indirect safety implications 
of the effects of schedule and other operational problems, however, were not 
overlooked. 

Based upon these goals, specific requirements were identified in terms of 
design characteristics, mission rules, operating procedures, personnel 
selection and training. Compliance with the requirements assured attainment 
of the goals. The requirements were met through performance of specific 
safety tasks using properly selected and tailored tools in accordance with 
the project schedule. 

RSRA project safety task requirements and the timing of task performance 
were based upon an extensive review of other developmental aircraft programs 
and documentation governing the development and implementation of NASA and 
military safety programs. The RSRA task and timing requirements were 
tailored from the approach outlined in NHB 1700.1 (Y3), shown below. 

It is anticipated that, in most cases, formal planning of the 
safety effort for support of the system feasibility studies would 
not be initiated. There are, however, several typical safety 
tasks that should be completed during these activities. These 
tasks then become the foundation for the planning of system safety 
efforts during the system definition, design, manufacture, test, 
and operation. These include: 

a. A review of pertinent historical safety data from similar 
systems . 


b. A continuing review of the gross hardware requirements 
and concepts, to maintain an understanding of the evolving system. 

c. A review of the proposed mission objectives. 

d. Completion of the planning for follow-on safety 
activities. 

e. The completion of preliminary hazard analyses to identify 
potentially hazardous systems and to develop initial safety re- 
quirements and criteria. 

f. Participation in trade studies with the results of the 
preliminary hazard analyses identifying highly hazardous areas, 
with recommendations as to the alternatives. 

g. Identification of the requirement for special contractor 
safety studies that may be required during system definition or 
design. 
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h. Estimation of gross resource requirements for the system 
safety program during the complete system life cycle. 

i. Preparation of an index document that identifies all per- 
tinent safety data developed during the life cycle of the system, 
such as the results of analyses, the criteria and requirements 
implemented, the results of special studies and the applicable 
historical data. This index is updated at the conclusion of each 
major increment of the system development or as determined by 
program milestone dates. 

The specific tasks performed by the RSRA project are discussed in Section 
2.4, and the project schedule and milestones are discussed in Section 2.4.6. 
The early definition of overall project safety tasks and their relationships 
with project goals and schedules was a key element in the safety success of 
the RSRA. 

System requirements surveyed for the RSRA included the Federal Aviation 
Administration (FAA) Regulations, Air Force and Navy military specifications 
(including the MIL-A-8860 series), and Army documentation. Requirements 
from these sources were evaluated against unique aspects of the RSRA, which 
included the research and development nature of the project; its design, 
development test and evaluation aspects (i.e., strictly controlled flight 
environment and highly instrumented hardware); and the skill levels of the 
operational people who would be involved. Based upon these considerations, 
it was determined that Army document AMC P-706-203 (Engineering Design Hand- 
book, Helicopter Engineering, Part 3 - Qualification Assurance) was the most 
appropriate. This was tailored paragraph by paragraph to the RSRA project. 
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Figure 2.3-1 presents examples of RSRA requirements compared to AMCP-706- 
203. 

-RSRA Vs. AMCP-706-203: PROPULSION SYSTEM TEMP. SURVEY- 


PARAGRAPH 

706-203 REQUIREMENT 

FULLY 
COMPLY ? 

RSRA PLAN /RESOLUTION 

• ,«.3.2 FLIGHT TESTS 

TAKEOFF AND CLIMB TO MAX 
ALLOWABLE ALTITUDE 

NO 

OBTAIN CLIMB DATA TO 3000* 


LEVEL FLIGHT AT SELECTED 
ALTITUDES WITH POWER 
RANGING FROM HOVER (iCE 6 
OGE) TO MAX 

NO 

HOVER ICE AT MAX WEIGHT; 
120 KTS AT MAX WEIGHT UP 
TO 3000*; WORST CONDITIONS 
IN ENVELOPE 

B.H.H INSTRUMENTATION 
AND DATA ANALYSIS 

TEMP MEASUREMENTS 

TEST CONDITION MEASUREMENTS 

NO 

NO 

SEE f.0.1 

ALL EXCEPT ENGINE 
COMPARTMENT FLOW RATE - 
SIMILAR INSTALLATION TO 
S-67 


CORRECT TEMPS TO HOT ATMOS, 
COMPARE DATA TO COMPONENT 
REQUIREMENTS 

YES 

YES 

NAS1-13000 TEMP LIMIT 
DNE LISTING 

8.4.S DOCUMENTATION 

PREPARE REPORTS TO INCLUDE: 




- OPERATING CONDITIONS/DATA 

YES 



- SYSTEMS PERFORMANCE REVIEW 

YES 

AS REGARDS OPERATING- LIMITS 


- OPERATING LIMITS IDENTIFIED 

YES 



Flgure 2.3-1 Comparison of RSRA and AMCP-706-203 Requirements 


The yardstick applied to the RSRA was that it must meet a level of safety 
equivalent to the Sikorsky Model S-61 helicopter, which is an FAA certified 
transport category aircraft qualified for Presidential airlift. The re- 
quirements and the rationale for their selection were documented and 
included in the RSRA AQP. 

The adaptation of an existing set of requirements to the RSRA project was 
effective and took maximum advantage of lessons learned on other programs. 
Serious errors of omission and commission can result, however, if extreme 
care is not exercised. A highly disciplined approach as illustrated by the 
Figure 2.3-1 example is essential. 

2.4 DEVELOPING THE PLAN. The authoritative dociment of tailored safety 
guidelines for the RSRA project was the AQP. The AQP specified those engi- 
neering tests or analyses essential for substantiating the airworthiness of 
the RSRA. It presented concepts, schedules, and procedures for conducting 
design reviews for verifying adequacy of design for airworthiness, including 
safety. It specified prerequisites for reviews leading to safety-of-fl ight 
release prior to first flights by the contractor. Finally, it specified 
prerequisites for acceptance testing of the RSRA by the Government. The 
contents of the plan are shown in Figure 2.4-1. 
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Essential characteristics of the plan are described in the paragraphs below. 
Detailed discussions of the implementing organizations are provided in 
Section 3.0 and directing and controlling functions are treated in Sections 
4.0 and 5.0, respectively. 

2.4.1 Defining Requirements . After the project safety goals were 
developed, the actions required to achieve them were defined. In a similar 
manner, the requirements for achieving those goals were based on the RSRA 
design characteristics, the operational envelope, and mission scenarios. 
Thus, the ultimate mission of the RSRA was a major factor in defining the 
safety requirements. Recognition of this fact is illustrated in the AQP 
excerpt shown below: 


Concept of Operation and Maintenance . - The RSRA will be operated 
and maintained in a research environment by highly qualified 
experimental test personnel. Research instrumentation installed 
in the RSRA, together with NASA/ Army data reduction and inter- 
pretation capability, will provide technical information necessary 
to monitor airworthiness of the aircraft. Planned service usage 
of the aircraft is 50 hours per year for 12 years, for a total of 
600 flight hours per aircraft. Therefore, airworthiness substan- 
tiation requirements that assume world-wide operation and 
logistics support, in hostile natural or tactical environments, 
with a large fleet of aircraft accumulating many flight hours, do 
not apply to the RSRA. Selected airworthiness substantiation 
requirements that apply to the RSRA concept of operation are 
specified in this AQP, 


Management attention to the ultimate mission of the RSRA permitted effective 
tailoring of the safety requirements and influenced safety- related decisions 
that occurred later in the project. The RSRA experience demonstrates the 
value of early identification and documentation of project requirements. 

With the project requirements and safety goals clearly defined, the actions 
required to achieve the goals were developed and documented in the AQP. 
An excerpt from the AQP defines these actions: 


Each of the requirements listed hereunder shall be performed and 
verified during design reviews, prior to safety-of-fl ight release, 
or prior to acceptance test, as scheduled in Section 3.7. Verifi- 
cation of satisfactory fulfillment of these requirements shall be 
documented by the Government in an Airworthiness Qualification 
Report (AQR), which shall be issued as an Appendix to the AQP and 
which shall form the basis for the preflight review and safety-of- 
fl ight release. Each action item identified as a result of these 
requirements shall be specifically identified in the Airworthiness 
Qualification Report (Appendix A), corrective action shall be 
assigned and implemented, and adequate resolution verified by the 
Government, to provide a complete audit trail through the disposi- 
tion of each action item. AMCP 706-203 is used as a guide in 
formatting the requirements of subsequent paragraphs herein, which 


21 



also specify government or contractor responsibility for com- 
p1 iance. 


Several noteworthy items appear in the above excerpt: (1) Performance of 
tasks leading to fulfillment of safety requirements was correlated with the 
development schedule; (2) the requirement that specific safety activities be 
performed prior to design reviews and scheduled tests directed the alloca- 
tion of resources for timely completion; and (3) this integrated approach is 
an essential ingredient of a successful safety program. 

Another significant item is that compliance with each requirement had to be 
sufficiently documented to provide an audit trail. All action items 
generated to satisfy the requirements, and steps taken to resolve each 
action item, were recorded in a single document, the AQR. Responsibility 
for entering concerns and their resolutions in this document rested with the 
project office. Action items resulted when identified hazardous conditions 
compromised the basic RSRA safety goals. The potential for compromising 
goals was determined by categorizing identified hazards as shown below. 


Category I - Conditions such that a malfunction will cause 
subsequent equipment loss and/or death or multiple 
injuries to personnel. 

Category II - Conditions such that a malfunction requires 
immediate corrective action for personnel or 
equipment survival, or that will result in being 
one failure removed from a category I situation. 


Category III - Conditions such that a malfunction will degrade 
performance but can be controlled without major 
damage or any injury to personnel. 

Category IV - Conditions such that a malfunction will not result 
in major degradation and will not produce equip- 
ment damage or personnel injury. 


Since hazards in categories I and II involved the potential for loss of 
life; the elimination or control of these hazards was required to achieve 
the RSRA safety goals. Elimination through design was not feasible in all 
cases, so it was necessary to provide alternate solutions. The "safe life" 
concept was employed whereby statistically representative samples were 
tested to predict the safe useful life of critical systems based on the 
concept that catastrophic failure modes existed and had finite proba- 
bilities. The "safe life" concept was applied to category I hazards. This 
precaution, together with emergency provisions, provided the most safety 
consistent with mission requirements. Category II hazards, one failure 
removed from category I, which could not be completely eliminated through 
design were addressed via redundancy and special procedures. 
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Fail -operational provisions necessary for satisfying project requirements 
were aimed at sustaining a failure and still allowing minimum mission objec- 
tives to be met. Design and safety requirements were not concerned only 
with single and dual failures. Fail -operational (i.e., continue operational 
following tw failures) requirements were specified when component unrelia- 
bility, environmental conditions and aircraft operating characteristics so 
required. More detailed discussions of implementation of these concepts are 
provided in Section 4.4. 

The rigorous approach described above was not warranted in all cases. 
Another method employed on the RSRA for verifying that a requirement had 
been met was to refer to a previously demonstrated safe system or configu- 
ration. Comparison of the RSRA to the demonstrated "safe" H3 (S-61) air- 
craft is an example of this method. Figure 2.4-2 shows some of the exhaus- 
tive comparisons made between the two vehicles. 



Figure 2.4-2 RSRA Safety/Reliability Analysis Report 
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Caution should be exercised, however, when qualifying systems or components 
by similarity. The similarity must apply not only to the hardware, but to 
its intended use by operating personnel, within the specified environments, 
and with other systems. 

In addition to the requirements imposed directly by the AQP, do‘s and 
don't’s for safety, reliability, and maintainability were contained in the 
design guides which were part of the System Requirements Handbook delivered 
and reviewed at the Preliminary Design Review (PDR). These documents, 
provided by the contractor, provided excellent technical reference material 
developed specifically for this project and included data derived from many 
years of helicopter experience. The System Requirements Handbook provided a 
very useful standard against which to substantiate that the RSRA met system 
and project requirements and was ready for research operations. 

The planning in the AQP led logically to the identification of specific 
safety tasks which, when accomplished, satisfied the requirements . 

2.4.2 Identifying Safety Tasks. The safety tasks performed on the RSRA 

project were structured to meet the requirements imposed by the AQP which, 
when satisfied, ultimately led to achievement of project goals. 

Basic safety tasks outlined in NHB 1700.1 (V3) are shown below: 

Identify the hazards in the system. 

Determine corrective actions that may be implemented to either 
remove or control the hazard or to provide alternatives. 

Recommend corrective action or alternatives to the appropriate 
management level for a decision to either resolve the hazard or 
assume the risk. 

Document those areas in which a decision has been made to assume 
the risk, including the rationale for the risk assumption. 


Specific safety tasks for the RSRA project were defined on the basis of 
these basic tasks and were documented in the AQP, as shown below. 


SYSTEM SAFETY: 

Hazard Analysis. - Contractor responsibility to perform system, 
subsystem and operating hazard analyses in accordance with con- 
tract NASl-13000, Supplement VI, Section 4.6, to identify and 
categorize hazards. Objectives of reviews shall be to eliminate, 
reduce to an acceptable level, or otherwise resolve any Category I 
and II hazards that are identified. 

Contract Documentation. - Contractor responsibility to submit and 
update catalogue following Preliminary Design Review (PDR) and 
final Critical Design Review (CDR), and prior to Flight Readiness 


24 



Review (FRR) and Pre-Flight Review (PFR) as specified in contract 
Supplement VI, Section 4.6 and as scheduled in the dociinentation 
requirements of supplement III. 

Corrective Action. - Government responsibility to incorporate as 
action items in the AQR a list of all Category I and II hazards 
identified; also, to review corrective action, verify acceptable 
resolution of the hazard, and docunent corrective actions and 
final resolution in the AQR. Conduct a safety review concurrently 
with each program review specified in Section 3.2. Responsibility 
- Rotor Systems Research Aircraft Project Office (RSRAPO), chief 
engineer. 

Safety Surveillance. - Government responsibility to monitor con- 
tractor program and identify as action items any additional 
hazards reported in accident/ incident reports, quarterly audits, 
hazard notification sheets, or hazard catalogue. Dociinent in the 
AQR all hazards identified, corrective actions and resolution. 
Responsibility - RSRAPO chief engineer. 

These tasks were tailored to the project in that selection, scope, and- depth 
were limited to that necessary and sufficient to demonstrate safety 
adequacy. Performance of these tasks supported the milestone schedule 
discussed in Section 2.4.6. 

This approach to accomplishing tasks was effective on the RSRA project. 
Exceptions taken to plan implementation in this area are discussed in Sec- 
tion 4.0. 

A word of caution relative to task selection and definition is that con- 
tracts should be scrutinized closely to ensure that necessary tasks are 
properly scoped and requirements imposed. The decision to exclude specific 
systems, subsystems, or operations should be made only if solid rationale 
for the exclusion is provided and documented. 

2.4.3 Establishing Safety Accountability . Establishment of safety goals, 
development of requirements enabling achievement of those goals, and defini- 
tion of implementing tasks were discussed in the preceding sections of this 
document. Responsibility, or more precisely, accountability, for task 
accomplishment leading to goal achievement involved the line organization, 
but also brought to bear other Center and NASA elements. 

Responsibilities and assignments were specific and assignees were held 
accountable for the adequacy, accuracy, and timeliness of their products. 
In short, everyone knew where the buck stopped. 

The RSRA AQP outlines those accountabilities. 

ORGANIZATION AND RESPONSIBILITY : 

RSRA Project Office . - The NASA/ Army Project Office is respon- 
sible for performing Government tasks defined herein and for 
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documenting in the AQR each Item of compliance or action require- 
ment. As assigned by each paragraph above, the RSRAPO will moni- 
tor contractor activity, review contractor documentation, verify 
compliance with contract requirements and program objectives, 
identify action items requiring resolution, and approve final 
disposition of action items and docunentation. RSRAPO will 
further provide data for the AQR documenting compliance with 
contract and program requirements and problem resolution. 
Specific RSRAPO responsibilities are assigned in Table 1. 

Langley Research Center (IRC) - Aviation Safety Officer 
(ASO) . - the Langley ^S0 ~is responsible for verifying that the 
RSRA i s airworthy, based on the data presented in the AQR and at 
project reviews. At the conclusion of PFR he will confirm that 
each prerequisite has been met and each open item resolved, with 
support from the RSRAPO, the Langley Aviation Safety Committee, 
and the RSRA Project Review Panel, as required. He will chair 
review teams at FRR, and PFR and will submit a memorandum docu- 
menting review determinations and findings, including recom- 
mendation for saf ety-of-fl ight release, for approval by the 
Director, Langley Research Center. 

Review Team Chairman : The chairman of other review teams will 

identify airworthinesss action items in the AQR, as required. 
RSRAPO cognizant WBS Managers will assure entry of action items in 
the AQR and verify disposition. 

Surveillance of the contractor program, as well as review, verification, and 
documentation of corrective actions as shown above were the responsibility 
of the RSRA Chief Engineer. 

The distribution of accountabilities as described in the AQP was very effec- 
tive on the RSRA project. The key to the success of the plan was the 
assignment of accountability high enough in the organizational chain to 
provide sufficient muscle to achieve assigned tasks. Implementation of that 
plan is discussed in Section 4.0, Directing, and illustrated in Figures 
3.2-1 and 4.1-1. 

2.4.4 Defining Safety Tools . The safety plan defines the safety tools to 
be used. Typical hazard identification tools are discussed in NHB 1700.1 
(V3) and other references. These include many forms as outlined in Figure 
2.4-3. 
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I 

RANDOMLY 

• SCENARIOS 

• DELPHI APPROACH 

SYSTEMATICALLY 

• HAZARD ANALYSIS (CONCEPTUAL, SYSTEM /SUB-SYSTEM, 
OPERATING, DECOMMISSIONING) 

• FAULT TREE ANALYSIS 

• SNEAK ANALYSIS 

• MANAGEMENT OVERSIGHT RISK TREE 

• OTHER SPECIAL STUDIES (FMEA, ETC.) 


Figure 2.4-3 Approaches to Hazard Identification 


Based on an understanding of project goals and experience with developmental 
aircraft, it was concluded that individual subsystem hazard analyses, a 
system hazard analysis, and an operating hazard analysis would be sufficient 
to cover the spectrum of safety requirements. From that premise, RSRA 
project management selected techniques from the relatively extensive menu of 
methods available for accomplishing hazard identification, and imposed the 
requirement for their use, as stated in Section 2.4.2. A discussion of the 
actual application of these tools is provided in Section 3.1. 

Additionally, a contractual requirement existed for performance of failure 
modes and effects analyses (FMEA's). Generally, FMEA's are recognized as 

reliability rather than safety tools. Previously prepared FMEA's can be 
used effectively in safety assessments by adding failure criticalities. 
This produces a Failure Mode Effects and Criticality Analysis (FMECA) as was 
done on the RSRA project. The intended mission of the aircraft made main- 
tainability and mission availability very minor factors. Consequently, the 
thrust of the FMEA's was redirected toward hazard identification rather than 
probability of failure determinations needed for availability and maintain- 
ability analyses. FMEA's were also useful in determining the potential 
safety impact of failures which occurred during testing. These applications 
of FMEA's on the RSRA proved very effective. 

This judicious FMEA tailoring is supported and indeed recommended by NHB 
1700.1 (V3) which states in part: 


The analysis methods may be expanded, reduced or altered as 
required to suit the specific needs of any separate program, or 
initiated during any time in the system development, thus assuring 
maximum flexibility. 

This concept reflects the certainty that all project performance and 
resource problems cannot be anticipated several years ahead of time. A 
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notable feature of the AQP was that flexibility was provided to use addi- 
tional safety tools or modify existing ones as the need was identified. 
This flexibility was exercised repeatedly throughout the project. 

2.4.5 Providing Information Flow . The RSRA project implemented a 
disciplined approach to information flow through the use of formal design 
reviews. These reviews served to evaluate current status of aircraft 
development and to disseminate required information to all organizations. 
As can be seen in the excerpt from the AQP shown below, safety activities 
were included in the design evaluation at the same level as hardware 
development activities. 

Concept of Project Reviews. - Preliminary Design Review 
(PDR) and Critical Design Review (CDR) will be conducted by sub- 
system (WBS level 3), immediately preceding design reviews of the 

Air Vehicle System (WBS level 2), as scheduled in figure 1. The 

review will be conducted at the contractor's facility or other 

location(s) agreeable to both the Contractor and the Government. 
Systems Engineering and Test and Evaluation elements will be 
incorporated into design reviews as they pertain to the system or 
subsystem under review. Flight Readiness Review (FRR) and Pre- 
Flight Review (PFR) will be primarily devoted to Airworthiness and 
saf ety-of-fl ight considerations. Pre-Acceptance Test Review 
(PATR) will be primarily devoted to RSRA system capability and 

readiness for research operations. Concepts of each review are 
summarized as follows: .... 

This planning illustrates the safety awareness of the RSRA project manage- 
ment. 

After each formal design review, the review chairman prepared a report to 
the RSRA project manager identifying action items and stating recommended 
resolutions. In addition, the review team chairman assigned actions which 
required systematic documentation as discussed in paragraph 2.4.3. These 
documentation procedures ensured that project management was aware of the 
risks involved and of the rationale associated with those risks. The docu- 
mentation also provided an audit trail. 

The flow of technical information was augmented in a less formal way at the 
weekly (each Monday morning) staff meetings. WBS managers presented their 
actual status compared to planned status and discussed problems encountered 
and the outlook for their work areas. It was necessary that they coordinate 
closely with their contractor counterparts to be up to speed at those 
meetings. A joint NASA/ Army management meeting was held monthly along 
similar lines, but with high level managers. One attempt to combine these 
two meetings was singularly unsuccessful because of the inhibiting effects 
of the presence of higher level managers. An important lesson learned from 
these meetings was that they should be held at the lowest level possible, 
consistent with the authority required. Discussion of problem areas tended 
to be suppressed in the presence of too much horsepower. 
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Both the formal and Informal methods for dissemination of information were 
effectively used on the RSRA project. The effectiveness of both methods was 
enhanced by establishing schedules which permitted timely generation and 
interchange of the required data. 

2.4.6 Scheduling Project Milestones . The coordination of safety and 
development activities was accomplished as planned in the AQP. The AQP 
identified the significant project milestones, the input data required, and 
the information to be delivered. Representative items considered were: 

a. AQP release and revisions. 

b. Initiation of each type of hazard identification analysis. 

c. Completion of each type of hazard identification analysis. 

d. A schedule of major reviews. 

The safety milestones appeared on the official project schedule as shown in 
Figure 2.4-4, and were clearly related to the project phases and major 
events. 

This approach kept safety in perspective. That is, an awareness of safety 
issues was maintained without overkill. It is concluded from the RSRA 
experience that safety activities contribute to project success when they 
are included in the mainstream of project activities and proper emphasis is 
maintained. 

2.4.7 Providing Safety Education . Safety education, training, and 
advisories were planned an^ provided as RSRA project changes dictated. The 
need for extra training came about as a result of transfer of operations 
from Wallops Island, Virginia, to Ames Research Center, California, 
resulting in general loss of corporate memory. Because of the "experimental 
shop" approach to documentation, incomplete transfer of personnel, and 
changed operational missions and roles, an aggressive training program was 
required. 

New personnel on the RSRA project had little specific previous system safety 
experience. Implementation of the RSRA project safety plan depended upon 
understanding and acceptance on the part of project personnel. Specific 
training was provided to staff personnel in a timely fashion to support 
overall project schedules. Training was tailored in terms of the orienta- 
tion, technical need, and complexity of the program. An outline of one of 
the safety seminars presented at Ames is shown in Figure 2.4-5. 
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RSRA 

AIRWORTHINESS QUALIFiaiiON PUN 
SCHEDULE 



REQUIREMENTS (30, 30A, 30C, 30D, 30E, 30F, 30C, 13) 

1C - COMPLETION OF SUBSYSTEM/SYSTEM HAZARD ANALYSES 
23 - COMPLETION OF FMEA'S 


Figure 2.4-4 Airworthiness Qualification Plan Schedule 




























SYSTEM SAFETY SEMINAR OUTLINE 


1, SEMINAR OBJECTIVES : 


(ME) INFORM - WHAT IS SYSTEM SAFETY? 

- HOW CAN IT BE ACHIEVED? 

(YOU) UNDERSTAND > REQUIREMENTS FOR AN EFFECTIVE 

SYSTEM SAFETY PROGRAM 
TECHNIQUES FOR PLANNING AND 
IMPLEMENTING 

(WE) CREATE - SAFETY ATTITUDE 

- SENSITIVITY TO AND AWARENESS OF 
RISKS/HAZARDS 

(WE) DEVELOP “ AN EFFECTIVE SYSTEM SAFETY 

PROGRAM PLAN 

- AN EFFECTIVE SYSTEM SAFETY PROGRAM 

- AN EFFECTIVE DIVISION SAFETY PLAN 

2. CONCEPTUAL DEFINITIONS 


3. ASSESSMENT (CURRENT SAFETY SITUATION) 

4. BASIC PRINCIPLES 


5. SYSTEM SAFETY TASKS 

6. RISK MANAGEMENT 


7. PREVENTABLE ACCIDENT CASE STUDY 

8. SAFETY PLAN - HELICOPTER TECHNOLOGY DIVISION 

9. RESEARCH AIRCRAFT SYSTEM SAFETY PROGRAM PLAN 


Figure 2.4-5 RSRA System Safety Seminar Outline 


31 



3.0 ORGANIZING . The RSRA AQP provided the framework for organizing project 
functions and personnel within the context of the schedule. The project 
manager assembled those elements and incorporated such intangibles as tech- 
nical competence, safety attitude, and motivation to produce a flexible, 
efficient, integrated team. 

3.1 ORGANIZING THE WORK. The work elements of the safety program within 
the project organization included controlling the configuration, selecting 
and applying tools for hazard identification, and reviewing the results of 
safety activities. 

3.1.1 Controlling Configuration . The RSRA project used the experimental 
shop approach to configuration control, as shown by the Figure 3.1-1 direc- 
tive, wherein the control process consisted primarily of red-lining the 
drawings and in some cases changing them to conform to the as-built con- 
figuration. 

NASA/ARMY ROTOR SYSTEMS RESEARCH AIRCRAFT (RSRA) 

SAFETY REVIEW BRIEFING 



Signature authority under these conditions was extremely important. 
Approval of all drawing changes required the signature of the Project Chief 
Engineer and the chief of quality control. Project success in this area 
depended largely on the close working relationships between the project 
staff and contractor personnel, augmented by the conscientious attitude of 
all involved. A problem resulting from this experimental shop approach is 
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discussed in Section 6.0. A lesson learned from this RSRA experience is 
that without unusual dedication and cooperation on the part of project 
participants, serious program level problems can result. If program dollars 
are a driver and minimum configuration control and docunentation require- 
ments are levied, it is imperative that essential documentation be defined 
and a requirement for its delivery imposed. NASA document JSC 07700, Volume 
IV, "Configuration Management Requirements," is an excellent reference. 

3.1.2 Selecting Tooils . Tools were selected for performance of the safety 
tasks after the c^Tiguration was defined. This applied whether the con- 
figuration dealt with a concept, the hardware, or an operation. 

Initial tool selection was based upon the intent of the AQP; i.e., each 
subsystem, its interaction with the total aircraft system, and aircraft 
operations were evaluated. The chronology in Figure 3.1-2 below shows the 
tools employed and the major project events supported. 


SUPPORTED 


f DELIVER FAILURE MODE AND EFFECTS 
ANALYSIS (FMEA) (EXCEPT ACTIVE 
ISOLATION AND BALANCE SYSTEM 
AND EMERGENCY ESCAPE SYSTEM) 

5/75 

RESPECTIVE 

< 

DELIVER PRELIMINARY HAZARD 
ANALYSIS (PHA) 

1/76 

POR'a and CDR's 


REVIEW OVERBEY REPORT 

5/76 



DELIVER FMEA AND HAZARD CATALOGUE 
(VICE SYSTEMS. AND SUBSYSTEMS HAZARD 
^ANALYSES) 

7/76 



FLIGHT READINESS REVIEW (FRR) 

7/76 



AIRCRAFT DELIVERY 

7/76 



PRE FLIGHT REVIEW (PFR) 

10/76 



SAFETY OF FLIGHT RELEASE (SOFR) 

10/76 



DELIVER FMECA FOR ACTIVE ISOLATION 
AND BALANCE SYSTEM 

7/77 



DELIVER FMECA FOR EMERGENCY ESCAPE 
SYSTEM 

1/78 



DELIVER FAILURE MODE EFFECTS AND 
CRITICALITY ANALYSIS (FMECA). FINAL 

10/78 



DEVELOP TOP LEVEL FAULT TREE 

1980 



PREPARE ELECTRONIC FLIGHT CONTROL 
SYSTEM (EFCS) FAULT TREE 

1980 



DEVELOP EFCS COMMON CAUSE FAILURE 
ANALYSIS (CCFA) 

1980 



DEVELOP EFCS SNEAK CIRCUIT ANALYSIS (SCA) 

1980 



UPDATE EFCS FMECA UPDATE 

1980 


Figure 3.1-2 RSRA Project Events and Supporting Safety Tasks 


Some subsystems were excluded from the analysis effort based upon either a 
previously proven track record or similarity to other subsystem or aircraft 
elements. Specifically excluded were standard portions of the RSRA airframe 
and standard S-61 flight hardware. These exclusions were allowed only after 
exhaustive comparisons and analyses confirmed similarity in terms of the 
physical hardware, its intended use, and anticipated operating environments. 
The exhaustive comparisons notwithstanding, cost and schedule penalties 
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eventually were incurred as a result of this practice because of the 
inherent inability to determine, a priori, the effects of operational 
history. The primary basis for excluding $-61 hardware was the maturity of 
its reliability data and the acceptable trends of reliability demonstrated 
in service usage. An example of a reliability comparison analysis between 
the RSRA and the S-61 Presidential Airlift helicopter is shown in Figure 
2.4-2. The exclusion of S-61 hardware constituted the first level of safety 
program implementation tailoring. 

FMEA's were the first safety-related analyses performed. They are discussed 
in a safety context here because of their later application. These analyses 
were done by the contractor at the subsystem level and initial deliveries 
supported their respective PDR's. Subsequent updates and refinements sup- 
ported the CDR's and system level reviews. When hardware schedule slips did 
occur (some reviews were accomplished incrementally) , the FMEA schedules 
were adjusted accordingly. This resulted in no adverse effects, except for 
two major schedule adjustments that occurred, which required special safety 
engineering attention. These were the AIBS and the EES development, which 
slipped with the result that the systems were not operational until after 
the first flights. Special analyses and reviews were conducted and opera- 
tional limitations imposed to allow flight without these systems. Schedule 
and cost penalties were controlled, and an acceptable level of safety was 
maintained. 

A preliminary hazard analysis (PHA) was performed by the contractor after 
completion of the initial FMEA's. The purpose of performing the PHA at this 
time was to identify areas requiring additional safety effort prior to the 
flight readiness review (FRR) which occurred 6 months later. A Notification 
of Potential Hazard report resulting from that analysis is shown in Figure 
3.1-3. 
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Figure 3. 1 3 RSRA Preliminary Hazard Analysis Report 


probably would have been more project effective to perform 
n PHA earlier. This would have enabled better early definition of safety 
requirements and potential problem areas requiring greater safety emphasis. 

indicated in Figure 3.1-3 are not 

avaiiaDie when a PHA is done. 

perfonning a PHA or top level fault tree 
attention on critical areas and identify the need for more 

helnfu?*irrfAf®'^ specialized studies. Properly timed, PHA results are 
helpful in defining tools and their applications. 
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Detailed safety analyses had not yet been performed to the subsystem and 
system levels, nor had operational considerations been fully addressed. 
These analyses were required and were planned to support the RR. Because 
the basic FMEA's had already been prepared and their further amplification 
was not needed, remaining allocated resources were diverted to the safety 
effort. In this case, the ability to meet research goals far outweighed the 
need to adhere to strict maintenance and flight schedules, considering the 
experimental nature of this project. Because of this, resources were 
reallocated from the reliability analyses to the safety effort. The FMEA's 
were amended to include a sheet "B" addressing safety issues, as shown in 
Figures 3.1-4 and -5 and thus became FMECA's. By adding "criticality," the 
hazards were addressed; by detailing the FMECA's to the subsystem level in 
addition to the system level, the system and subsystem levels of hazards 
were addressed. 
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Figure 3.1-4 RSRA FMEA Example 
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Figure 3.1-5 RSRA FMECA Example 


This was a second major tailoring of safety program implementation and, 
although not rigorously identical to system hazard analysis (SHA) and sub- 
system hazard analysis (SSHA), it at least served the essential purposes. 
The FMECA ‘s were developed, reviewed, and appropriate implementation actions 
initiated through the combined efforts of system designers, safety engi- 
neers, and hunan factors personnel. The total FMECA, which generally ful- 
filled the purpose of the SSHA's and SHA's, was reviewed in-depth by all 
levels of contractor and Government project personnel. A hazard catalogue 
was produced to identify those issues requiring resolution prior to flight. 

This approach focused the needed technical capabilities and resources on 
solving the real-world RSRA problems. It is an example of initiating the 
safety analysis activity in a single format and "maturing" it as the project 
progresses. Pitfalls in this approach are that, because of the detailed 
nature of the FMEA, system- to- system relationships may not be considered, 
and operating personnel and environment considerations may be overlooked. 
Great caution should be used in exercising this option. NHB 1700.1 (V3), 
Section 2, "Technical Methods," and MIL-STD-882A are excellent references 
for system safety tool application. 
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The FMECA's for the AIBS and EES were completed prior to the operational use 
of those systems, but subsequent to initial RSRA flight. They were prepared 
with the same rigor as the other analyses. Interaction with the previously 
analyzed systems was considered in formulating the final FMECA. This last 
step, relooking at work previously completed, was an essential step made 
necessary by the waterfall completion schedule. 

Several other limited safety analyses were performed later in the project. 
Sneak Circuit Analysis of the EFCS planned early in the project was deleted 
in the interest of cost savings. It was performed much later after more 
costly alternate studies and tests were completed. The cost-safety trade 
(in favor of cost in this case) in retrospect, was not cost effective. In 
the words of the Project Manager, "Doing Sneaks early would have saved money 
(guess 10:1 payback) in fixing drawing errors. It also provides early 
identification of hazards or early confidence that they've been shaken out." 
Figure 3.1-6 shows one of the Sneak Circuit Reports delivered. 

Other analyses performed late in the project included a top-level fault 
tree. Figure 3.1-7, a detailed EFCS fault tree. Figure 3.1-8, and an EFCS 
Cornnon Cause Failure Analysis (CCFA), Figure 3.1-9. 
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Figure 3.1-6 RSRA Sneak Circuit Example 





Figure 3.1-7 RSRA Fault Tree Analysis Example 
(Top Level Fault Tree) 



Figure 3.1-8 RSRA Fault Tree Analysis Example 
(Detailed Fault Tree) 
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CRITICAL FUNCTION 
SET 


COMMONALITY 


CRITICAL EVENT 


I ACHU AILERON 
POSITIONING 

A portion of the EFCS 
aileron control interface 
I is provided by ACMU #1. 
Printed circuit card A6 
provides for control of 
the two aileron EFCS 
actuators, while card A8 
provides W control of 
the two aileron Series 
Trim actuators. A single 
event which causes loss 
of these outputs from 
both cards would result 
in inability to command 
aileron movement by the 
EFCS. 


CONNECTOR XA8, ACMU #1 


Pin 3 = 
Pin 4 = 
Pin 5 = 
Pin 6 = 
Pin 24 = 
Pin 25 =» 

Pin 29 = 

Pin 30 = 
Pin 31 - 
I Pin 32 = 
Pin 33 = 

|Pin 34 “ 

Pin 35 = 
Pin 36 = 
Pin 37 = 
Pin 38 = 
Pin 42 - 
Pin 43 - 
Pin 44 “ 
Pin 45 * 
Pin 46 = 
Pin 47 = 
Pin 48 = 
Pin 52 = 


P6l 

+15V SI 
-15V SI 
S61 

AIL COMP IN il>l 
AIL TRIM n 
ENG. SIG. 

AIL TRIM n 
NO. 1 RATE SIG. 
AIL COMP IN §2 
TO EFCS II 
TO EFCS #2 
AIL TRIM II 
TRIM EXT. 

AIL TRIM II 
TRIM RET. 

EP STK TRM BP SW 
EP STK TRM BP SW 
EP STK TRM BP SW 
EP STK TRM BP SW 
SG4 

-15V S4 
+15V S4 
SG2 

-15V S2 
+15 S2 
PG2 

AIL TRIM #2 
ENG. SIG. 


(Continued) 


1. Pins 4, 44, 
and 47 open. 


2. Pins 5, 43, 
and 46 open. 


3. Pins 6. 42. 
and 45 open. 


4. Pins 4. 43, 
and 46 open. 


5. Pins 4, 42, 
and 45 open . 


6. Pins 5. 43, 
and 47 open . 


7. Pins 6, 42, 
and 47 open . 


8. Pins 5, 44, 
and 47 open . 


9. Pins 5, 42, 
and 45 open . 


Figure 3.1-9 RSRA Coitimon C 
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Failure Analysis Example 



These later analyses reflected the project manager's interest in ensuring 
that all areas had been addressed. The top-level fault tree identified the 
major areas of concern and subsequent review showed that all areas had been 
adequately covered in the FMECA and other studies. 

The use of top-level fault tree analyses (FTA's), late in a project, is an 
effective tool for identifying problem areas overlooked or not properly 
addressed. Properly done, they can trigger a relook at previously completed 
analyses to verify their sufficiency. 

The EFCS detailed fault tree and common cause failure analyses were accom- 
plished in response to the project manager's concern that a third party 
review this safety critical area in which the project staff had the least 
expertise. While these analyses did not reveal any previously unidentified 
hazards, they served two very important purposes. First, they established 
confidence in the safety adequacy of the EFCS itself; second, they enhanced 
the credibility of the other system and subsystem analyses that had been 
performed. 

In summary, project implementation in terms of techniques applied deviated 
from the plan. These deviations resulted from conscious decisions based on 
real-time needs and complied with the intent of the plan to produce a safe 
RSRA. 

3.1.3 Assigning Review Authority and Methods . RSRA safety decisions were 
based u^n i nformed positive acti ons . Ri sk was accepted, when necessary, by 
a conscious act, not through default. The project manager bore the ultimate 
responsibility for overall project safety, but he delegated authority for 
safety functions to his Chief Engineer, Review of safety matters was an 
integrated staff function, which was conducted at several levels throughout 
the organization. Activities ranged from the daily routine to rigorous 
formal committee action involving the Center Director. The subsystem 
managers reviewed the hazard analysis reports in-depth, working with 
detailed drawings, schematics, and other data. They consulted with staff 
technical personnel and outside experts when needed. They asked questions 
to establish credibility of the problem, investigated its potential impacts 
and concurred in appropriate resolution decisions. Those problems not 
immediately resolved were entered in the AQR and presented at major reviews 
(PDR, CDR, etc.). Resulting actions were reviewed by the Chief Engineer and 
approved by the Project Manager and the Aviation Safety Officer for all 
except safety-of-fl ight release, which required Center Director approval. 

3.1.4 Providing Information Flow . The AQP specified the input and output 
data which flowed thro ugho ut the organization, between organizations and 
between the contractor and project office for the RSRA. Figure 3.1-10 
provides a representati ve data flow leading up to Safety- of** FI ight Release 
for the aircraft. 
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Figure 3.1-10 RSRA Concern Resolution Process 


Formats, origins, and uses of information were described to guide project 
participants. In other words, after a hazard was perceived, the AQP 
described how it should be reported. It also addressed v^o should document 
the hazard and in what format. The AQP described where it went from there 
and who evaluated it. The plan covered how the evaluation was to be coordi- 
nated and recorded. It specified who was to be involved in resolution of 
the hazard and how that resolution would be implemented. Recording the 

implementation of the resolution was likewise specified in the AQP. Visi- 
bility provisions and documentation retention for reviews were also 
addressed. This systematic and disciplined approach established a docu- 
mentation audit trail for closeout of identified risks and ensured that 
closeout actions did not occur on paper only. 

Significant features of the AQR as reflected in the figure are: (1) Re- 

tention in the master listing of all concerns identified during the life of 
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the project, their origins, and resolution actions required (this consti- 
tuted an excellent audit trail and minimized unnecessary re-review of issues 
already put to bed); (2) use of the summary listing to provide a compre- 
hensive index of all closeout documentation; and (3) concerns entered in the 
Program Review Airworthiness agenda list "tagged" for resolution by a 
specific major review. 

The summary lists were a reordering of the master list and in effect estab- 
lished a prioritized ranking of concerns. Information on issues requiring 
resolution by or at the next milestone review was always readily available. 

Those problems having the greatest programmatic impact were assigned to the 
"top ten." This group, not necessarily limited to ten, represented those 
issues which were potential "show stoppers." Representative problems (some 
of v^ich are safety related, some simply programmatic problems) are shown in 
Figure 3.1-11. 


1. 

CALIBRATION FIXTURE EAC EXCEEDS BUDGET 

- 

NOT FAILURE 

- PROGRAMMATIC 

ISSUE* 

2 . 

AIBS DESIGN CONCEPT 

- 

NOT FAILURE 

- PROGRAMMATIC 

ISSUE* 

3 . 

FLIGHT TEST CONCEPT 

- 

NOT FAILURE 

- PROGRAMMATIC 

ISSUE* 

4. 

DESCOPINC 

- 

NOT FAILURE 

- PROGRAMMATIC 

ISSUE* 

5. 

INADEQUATE PYRO. QUAL. SCHEDULES 

- 

NOT FAILURE 

- PROGRAMMATIC 

ISSUE* 

S. 

BSA FAILS TEMP/HUMID CYCLING 

- 

ITEM 2 



7. 

ANALYSIS INDICATES INTERFERENCE IN ESCAPE 
TRAJECTORIES 

- 

ITEM 4 



8. 

APPARENT CROSS INACCURACY IN ROTOR LOAD 
MEASUREMENTS 

- 

ITEM 3 



9. 

A1 BLADDER DEVELOPMENT AND QUALIFICATIONS 

- 

ROUTINE DEVELOPMENT 


10. 

AIRCRAFT 13 INSTRUMENTATION INSTALLATION AND 
CHECKOUT SCHEDULE 

- 

NOT FAILURE 

- PROGRAMMATIC 

ISSUE* 

11. 

WING TILT ACTUATORS DID NOT OPERATE IN HARMONY 

- 

ITEM 8 



12. 

ACCUMULATOR THREAD FAILURE DURING PROOF 
PRESSURE TESTS 

- 

ROUTINE DEVELOPMENT 


13. 

A1 BLADDER QUALIFICATION (AGAIN) 

- 

ROUTINE DEVELOPMENT 


U. 

A1 DAMPER NULL PRESSURE SENSITIVITY TO TEMPERATURE 

- 

DESCOPED 



15. 

SAS AND SERIES TRIM ACTUATOR PROCUREMENT/ 
QUALIFICATION 

- 

ROUTINE DEVELOPMENT 


18. 

LATE COMPLETION OF SEAT DESIGN. DEVELOPMENT 
AND QUALIFICATION 

- 

ITEM 5 



17. 

UNRESOLVED CRITICAL FAILURE MODES 


NOT FAILURE 

- PROGRAMMATIC 

ISSUE* 


* COST PROBLEMS REQUIRED DESCOPINC 


Figure 3.1-11 RSRAPO Program Development Problems - Top Ten 


The status of the top ten problems and the actions to assure their resolu- 
tion were regularly presented for NASA Center management review. This 

technique was a very effective method of prioritizing project efforts. In 
the words of the RSRA project manager, "When you tell upper management what 
your potential show-stopper problems are, you can be sure you get their 
attention, their guidance, and their help (possibly even more than you think 
you need!)." 
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This focused attention might lead to fear of an overkill on problem resolu- 
tion. RSRA experience indicated that such extraordinary effort on project- 
critical problems was appropriate. The process of identifying, assessing, 
and resolving concerns identified at reviews, together with the detailed 
documentation procedure, serves as an example for future programs. Well 
planned and timed reviews and thorough, traceable documentation were major 
factors in the success of the RSRA project. 

3.2 ORGANIZING THE PEOPLE. Special inter- and intra-organi zational rela- 
tionships were established in the formation of the RSRA project team. 
Safety task requirements and organizational responsibilities were imposed by 
the AQP: 

Flight Readiness Review. - Conducted two months prior to first 
flight of each air vehicle configuration (helicopter, compound, 
fixed wing, and with active isolator). Chaired by the Center 
Aviation Safety Officer (ASO). Contractor WBS Managers for 
Design, Test, and Systems Engineering will substantiate the air- 
worthiness and safety- 0 f-fl ight release, the flight development 
buildup plan, safety-of-fl ight provisions, and emergency proce- 
dures. Review Chairman, assisted by Secretary, will identify open 
action items and will submit report of determinations and recom- 
mendations to the Project Manager. 

Pre-Flight Reviews. - Conducted just prior to first flight of each 
air vehicle configuration. Chaired by the Aviation Safety 
Officer. Open items from FRR are reviewed to confirm acceptable 
resolution. Review chairman will verify that airworthiness and 
safety requirements have been satisfactorily achieved, and will 
report determinations and findings, including reconmendations for 
safety-of-fl ight release for approval by the Director. 

Review Action. - Government responsibility to participate in 
reviews as specified in NASA/ Army Project Directive Number 1. 
Government or contractor review team members shall use the Request 
for Action (RFA) form to identify any elements of noncompliance 
with specifications, with program requirements or with program 
objectives as they affect airworthiness, safety, or Reliability 
and Quality Assurance (R&QA). RFA action assignees will incorpo- 
rate action items in the AQR, and will review corrective actions 
and verify resolution. Responsibility - Review Team Chairman to 
assign action by RFA and provide report of review determinations 
and recommendations. 

The authority to implement those requirements was delegated to the NASA RSRA 
Project Chief Engineer. The resulting organization was designed to optimize 
the flow of information and maximize the benefit to be derived from avail- 
able skills and training. Additionally, the organizational structure paral- 
leled the contractor's to balance the interfaces and facilitate coordina- 
ti on . 
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NHB 1700,1 (V3), "System Safety," contains the following statement relative 
to the safety function and its place in the organizational structure. 

... it should be placed in the reporting chain at a point which 
allows the risk evaluation output resulting from the safety effort 
to flow directly to the appropriate level of management in support 
of risk management decisions. 

The RSRA safety function was implemented through the Project Chief Engineer, 
who had direct access to the project manager, the Aviation Safety Officer, 
and the Center Director. He had sufficient authority to implement safety 
requirements and appropriate problem resolution measures. 

Although only one NASA employee carried the "safety" label, it was not a 
one-man show. The functional safety effort complied with NHB 1700.1 (V3), 
which states: 

The organization of the functional system safety effort is 
developed to accomplish the tasks set forth in the safety plan. 
Safety may be part of the system engineering organization or part 
of a systems effectiveness organization, collocated with the 
reliability, quality or maintainability organizations. As a 
general rule, to maintain objectivity and the check and balance 
system, it is preferable that system safety not be part of the 
design engineering organization. 

The RSRA Project Chief Engineer was also the System Engineer Manager, and 
the System Safety and R&QA managers reported to him. Tailoring safety 
requirements to the project in terms of organization involved collocating 
the safety engineer with the systems engineering organi zation, and the 
sharing of safety responsibilities by all WBS managers. The RSRA experience 
shows that this arrangement can be effective; however, it also raises a 
question: Would this arrangement be as effective on other projects or 

should its success be attributed more to the safety attitude and competence 
of the RSRA staff? 

The NASA focal point for safety matters was the project safety engineer, 
whose authority was through the Chief Engineer. A safety counterpart was 
designated in the contractor's shop and close coordination was maintained 
between the two. These individuals were the focal points in their respec- 
tive organizations; however, they did not have sole responsibility for RSRA 
safety. Other in-place NASA elements were employed on a consultation basis, 
or as sounding boards when conditions merited. The RSRA staff was involved 
in each level of project safety activity. The organizational concept that 
each Work Breakdown Structure (WBS) manager was actually a miniproject 
manager was significant. Each of these managers was responsible for tech- 
nical performance, cost, schedule, safety, reliability, and other facets of 
his WBS element. By involving the project organization in developing the 
plan, each WBS manager had to address what he would do to support project 
safety. Thus management on the RSRA project was knowledgeable concerning 
system safety and was keenly aware of safety as an integral component of 
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project success. This safety-conscious attitude pervaded the organization 
and resulted in a continuous team effort to include safety in mainstream 
project activities. 

An important lesson learned is that by organizing for safety, the experience 
of other staff members and in-place organizations can be used effectively to 
augment even an austere safety program. 

3.2.1 Providing Required Information 

The success of the RSRA project in general and the safety program in partic- 
ular, depended upon acquisition, generation, and dissemination of informa- 
tion. This included information generated by the contractor as well as the 
project office. The most effective organization for accomplishing this was 
one consistent with the contractor organization. Accountability for safety 
resided with each director as described in NHB 1700.1 (VI). Accountability 
was further distributed to project managers together with the required 
authority. The structure for safety accountability and authority within the 
RSRA project was documented in the AQP. The organization for safety is 
illustrated in Figure 3.2-1. 

The organization provided for subsystem responsibility as well as technical 
discipline responsibilities not limited to a specific subsystem. An impor- 
tant feature was the establishment of a safety focal point. Participation 
of all staff members in safety activities provided comprehensive safety 
capability through coordination by the focal point. 

The RSRA project office used the classic NASA concept of penetrating the 
contractor's activities in detail. The data clause in the contract gave the 
Government access to all contractor internal documentation related to the 
contract. Similar penetration of subcontractor activities was provided and 
pursued. One problem in this area resulted from the Emergency Escape System 
(EES) contractor's insistence on a firm fix^ price contract with a propri- 
etary rights provision. This contractual arrangement resulted in consider- 
able difficulty in obtaining the information required for the necessary 
hazard analyses. The problem was overcome only by developing a close pro- 
fessional relationship between the Government and the subcontractor. 

3.2.2 Using Skills and Training . The broad range of disciplines spanned by 
the safety tasks dictated the use of many skills. The entire project 
organization was, in fact, available to support the safety function. Safety 
concepts and techniques were essential to meeting the safety criteria, but a 
large staff of safety engineers was not considered necessary. In fact, only 
one project office person had "safety" in his title, and he also handled 
other system engineering disciplines (aerodynamic performance and mass 
properties). The project team itself was safety conscious and possessed the 
requisite system technology as well as technical design and development 
engineering skills. A single safety engineer, operating through the Chief 
Engineer, spearheaded RSRA safety activities. Safety consciousness of the 
project was fostered by safety seminars, coordination of safety activities, 
and, most importantly, by the project manager's positive attitude. Unique 
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Figure 3.2-1 RSRA Safety Accountability Structure 





capabilities of individuals played a significant role. As an example, both 
Government and contractor flightcrews and flight test engineering teams 
performed simulations and chalk-talk walkthroughs of stability and per- 
formance envelopes, normal operating procedures, and emergency procedures. 
They participated in pre- and postflight briefings and data reviews. Inves- 
tigation of the cockpit layout by a flight crewnember in the design phase 
identified a control which operated opposite to the pilot's natural reac- 
tion. The design was changed to accommodate the natural reaction. Such 

perspective added a dimension normally unavailable, even in large safety 

organizations. 

A lesson learned is that a very small safety staff can be effective if 

proper management support is provided. Don’t try to out-engineer the 
experts. Technical quality of the safety product is enhanced vAien a safety 
expert guides the development of safety analyses through the knowledge of 
designers and system specialists. Assistance from sources external to the 
project was actively sought and encouraged. Senior people in diverse fields 
supported scheduled reviews. Since they weren't connected with the program, 
they had different perspectives and provided insight not normally available. 
A roster of participants in such RSRA safety reviews is shown in Figure 

3.2-2. 


1 DATE 

REVIEWS 


TYPICAL PARTICIPATION 

NOV. 

11, 197« 

PDR 



f 

PRIME CONTRACTOR (SIKORSKY) 

FEB. 

6, 1975 

DESIGN REVIEW 



SUBCONTRACTORS (STANLEY. TMS) 

JUNE 

5, 1975 

AFT FACING SEAT TECH. REVIEW 



CONSULTANTS (McD/DAC. GRUMMAN) 

JUNE 

9. 1975 

CDR 



RSRA PROJECT OFFICE 

NOV. 

7, 1975 

DEVELOPMENT STATUS REVIEW 


^ < 

LaRC, SED, RSSQA 

JAN. 

30. 1976 

DEVELOPMENT STATUS REVIEW 


AMRDL 

FEB. 

11, 1976 

DEVELOPMENT STATUS REVIEW 



AFSC HAFB TEST TRACK 

AUG. 

10, 1976 

FINAL CDR (TEST READINESS) 



AFSC/ASC B-1 (OSCAR SEPP) 

APR. 

19, 1977 

TEST RESULTS REVIEW 



USAF McCAFB (DAVE KETCHESON) 

JUNE 

16, 1977 

QUALIFICATION REVIEW 



NASC (FRED QUILL) 






USAMC (COL. DR. W. SCHANE) 





JPL (NAT. PRESCOTT) 





JSC (THOMAS CRAVES) 





DFRC (BRUCE PETERSON) 





USAF KAFB B-S2 (ELLIS SMITH) 


Figure 3.2-2 NASA /Army Rotor Systems Research Aircraft Project 
Safety Review Briefing, EES Review Participation 


3.2.3 Avoiding Cultist Attitudes . The potential for "cult" development was 
recognized by the RSRA project manager. Through close coordination and 
personal involvement in the project, he maintained a balance between the 
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needs of the project and the "wants" of individual discipline practitioners. 
Even though this project was relatively small, there was the risk of tech- 
nical specialists (e.g., safety, R&M, weight and balance) wanting to stress 
compliance with their specialty disciplines at the expense of more essential 
work. When the Chief Engineer uncovered an unanticipated fatigue strength 
uncertainty, he "horse- traded" manhours from some of the "ility" effort to 
the more critical fatigue analysis. The tradeoff, which redirected scarce 
resources from lower priority mission availability analysis effort to accom- 
plishment of essential safety studies, is a classic example of acute manage- 
ment awareness of the "cult" problem. 

3.2.4 Balancing Contractor Interfaces . The organization of the RSRA 
project office paralleled that of the contractor’s project. This resulted 
in a one-on-one working relationship at the subsystem level. This arrange- 
ment resulted in a cooperative working relationship providing mutual bene- 
fit, once the Government team had "earned their spurs" by convincing the 
contractor engineers of their technical competence and set aside fears of 
Government spying. 

At least one case existed on the project where a member of the project 
office displayed deficiency in both performance and in interfacing effec- 
tively with the contractor. The project manager chose the difficult solu- 
tion of prohibiting that person from traveling to the contractor's plant 
and, eventually, forcing his transfer out of the project without replace- 
ment. This required combining efforts by the project manager and other 

project personnel to fill the void. 

While close technical cooperation between Government and contractor per- 
sonnel was essential, it was the responsibility of NASA project management 
to ensure the highest reasonable quality of product consistent with cost and 
schedule constraints. It was at times necessary to adopt a "show-me" atti- 
tude. This adversary relationship is best illustrated by the one-on-one 
review of the contractor produced FMECA's. Tlie contractor was frequently 
challenged to provide rationale for his classification of hazards, or sub- 
stantiate supporting data. It was a fine line to be walked, and not always 
successful, as related above. 

3.2.5 Facilitating Coordination . Most aspects of the coordination that 
occurred during the RSRA project are discussed elsewhere in this docunent. 
However, problems associated with the contractor's remoteness of location 
from the NASA project office deserves special attention. A discussion of 
the relocation of the project offices and flight test operations from 
Langley to Anes is provided in a later section. Real-time communications 
between the East Coast contractor facility and the West Coast Government 
facilities were burdensome at best. Extended Government and contractor 
personnel travel was required, and less person-to-person communication 
occurred. Successful project performance was achieved, but only through 
personal dedication, much added cost, and considerable personal incon- 
venience. 
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3.2.6 Cultivating an Ombudsman . Differing professional opinions are not 
uncotimon"; When this occurs , suppression of concerns sometimes results, 
especially in the case of disagreements between people related vertically in 
an organization chart. This problem was circumvented on the RSRA project 
with an ombudsman -- a person to hear the concerns of others on an unbiased 
basis. 

An individual emerged from within the project to fulfill this function. 
Although his primary duties were not safety, his work was closely related to 
safety; he was perceptive; he had high integrity and tact; and he was 
interested. On many occasions he acted as a go-between to get things done 
informally, which may never have been accomplished through the formal route. 
Through this medium of communication, problem causes were isolated without 
fear of "punishment," Liaison was augmented and corrective actions and 
project improvements implemented. 

The "lesson learned" is to be sensitive to, and encourage, the emergence of 
such informal channels of communication. 



4.0 DIRECTING 


Risk Management applied to the RSRA involved the process of identifying 
risks, reducing them, controlling those that couldn't be reduced, making 
conscious (not by default or ignorance) decisions to accept risks, and the 
discipline to make all of the above happen and to track the resolutions. 
This section addresses the elements of direction necessary to achieve effec- 
tive project risk management. 

4.1 ASSIGNING SAFETY ACCOUNTABILITY AND AUTHORITY 

Specific RSRA accountabilities, provided for in the AQP, are illustrated in 
Figure 4.1-1. 




TABLf. 1, - AIRfcOMIllINF.SS (JUALIFICATION RJVII* 

ITTWS 





STATUS THKMII IS, 1978 




MBS 

Contract Data Item 
Supplement III 

ITIW 

RSRA RESPONSIBlLm 

DUE HATE 

NOTES: 


System 

1C 60 DA POR 

Hazard Catalogtie 

Systems Engineering 

9/16/74 

X SER72012 

9/9/74 

Safety ( 
Reliability 

1C 60 M CDR 
1C 90 DB PFR 

Hazard Cat. , Rev. 1 
Hazard Ott., Rev. 2 

Systems Engineering 
Systems Engineering 

8/11/7S 

6/7/76 

X SER72012 
X PML 76-558 

7/24/75 

7/8/76 


1C 30 UB PFR 

Hazard Cat., Rev. 3 

Systems Engineering 

8/7/76 

X R4L 76-358 

7/8/76 


lA PFR 

Preflight Safety Rept. 

Systems Engineering 

9/7/75 

X FRR Rept. 7/8/76 
« PFR AQR Appendix A 


IB 

Accident Report 

Systems Engineering 

As required 

N/A 



ID 

Hazard Notification 
Sheet 

Systems Engineering 

As required 

N/A 



23 ISDB CDR 

FMEA's except AI 6 EES 

Systems Engineering 

12/27/7S 

X CIXl Rept. 

6/1/76 


23 ISDB CSR 

FMEA/AI 

Systems Engineering 

6/30/77 

X SER Due 

1/30/78 


23 ISDB BCS Qual.Rev. 
23 ISDB Cca^. FRR 
23 Delivery 

FJCA/EES 

FMEA/Conp. ♦ F.FCS 
BEA Final Revision 

Systems Engineering 

Systems Engineering 
^stofts Engineering 

4/30/77 

4/30/77 

9/30/7S 

X RSRA 1149 
t FRR Report 

7/13/77 

7/29/77 


19 

Failure Reports 

Systems Engineering 

As required 

N/A 


Design Data/ 
Documentation 

2 10 DB PDR 

Perf. Stability 
Control Rept. 

Systems Engineering 

6/9/74 

X SER72006 

6/21/74 


2 330 M PDR 

Perf. Stability/ 
Cont. Rept., Rev. 1 

Systems Engineering 

5/16/7S 

X SER72006 

3/18/76 


2B 10D6 FOR 

Fit. Cont. Sys. 
Design Report 

NB5 Manager 

6/25/ 74 

X SER72007 

6/20/74 


3 lODB PDR 

Structural Criteria 
Weights Report 

Systems Engineering 

6/29/74 

X SER7200S 
X .St-31' 20(14 

6/20/74 

4/30/74 


Figure 4.1-1 RSRA Safety Accountability Assignments 


RSRA project management recognized that the manner in which assignments and 
authority were distributed throughout the organization was important. If 
the majority of the safety issues were the responsibility of the most junior 
engineer on the project, and he alone was held accountable, the value 
assigned to safety would be obvious, and the product would be less than 
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optimum. Every member of the staff, from the chief engineer to the junior 
engineer, had a definite role in ensuring safety. The subsystem managers 
were keenly aware of cost and schedule impacts of their subsystems on the 
overall project since they were held accountable for these items. The RSRA 
risk posture was enhanced when these managers were also held accountable for 
safety, as illustrated in Figure 4.1-1. To discharge this added responsi- 
bility, the RSRA subsystem managers developed a productive and close working 
relationship with their contractor counterparts. For example, the FMEA 
results prepared by the contractor were reviewed in detail by the subsystem 
managers and their technical people, to fully explore the impacts of identi- 
fied failure modes. 

4.2 FOSTERING SAFETY ATTITUDES. Safety awareness was part of daily project 
activity. An atmosphere of openness among staff members permitted discus- 
sion of the cost of performing each safety task. Schedule slips were freely 
discussed at all levels. No one liked added costs or schedule slips, but if 
staff members had failed to address these subjects, many safety problems may 
have been temporarily suppressed only to surface later. 

The RSRA project manager’s attitude was instrumental in the success of the 
project safety program. He was willing to consider opportunities, and was 
consistent in his willingness. He conveyed to his staff his willingness to 
consider every safety concern identified, when it was identified. He 
believed that safety tasks were finite, TderTti f iabl e , definable, and 
do-able, and that if the tasks were competently done they would reduce 
accidents. In short, he believed that safety contributed to the betterment 
of the project, and was not just extra work. He conveyed to his staff his 
conviction that safety was important. 

Cartoons and other types of humor were not uncommon during the course of the 
RSRA project. They were a subtle reminder of the need for safety awareness. 
The project manager didn't encourage humor -- he just let it happen. Humor, 
whether in cartoons or other forms, is a method of communication. The 
attitude of the staff and their concerns about the project were often con- 
veyed in this way. 

4.3 ENSURING INTERFACES. Communication was key to directing all aspects of 
the project. It was especially crucial in safety areas. One of the most 
common and most useful methods of communication was the staff meeting. The 
staff meeting provided the opportunity to convey matters of safety to those 
most closely associated with the project. It also cut across organizational 
boundaries and involved everyone in safety issues. 

Significant, but less formal communications occurred daily in the develop- 
ment process. In RSRA, as in any development project, numerous conversa- 
tions occurred between the Government project manager and the contractor 
project manager. Impromptu meetings, telephone calls, etc., were essential 
to getting the job done. It is probable that more progress was made through 
this type of communication than through the more formal meetings and 
reviews. Major agreements or decisions made in informal communications were 
docLinented. RSRA project management was very successful in establishing 
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informal two-way communication with contractor technical personnel vrfiile at 
the same time observing the "arm’s length" philosophy. This was, in fact, 
the communication mechanism through which resolution of the RSRA fatigue 
substantiation problem discussed in Section 5.3 was brought about. 

4.4 RESOLVING HAZARDS. Hazard identification tools, information flow for 
transfer of technical data, and milestone review participation were 
described in earlier sections. These activities, in concert, yielded a 
shopping list of safety issues requiring evaluation and resolution. 

Hazard resolution activities, specified in the AQP, were assigned to staff 
personnel at the working level, were formalized through major review activi- 
ties and were documented in the AQR. The techniques applied were largely 
the same whether resolution was accomplished within the project, through the 
assistance of outside panels and committees, or by review board directed 
activity. 

Hazard evalution and resolution techniques were not defined in the AQP; 
therefore, RSRA project management planned for and implemented a systematic 
approach similar to that outlined in MIL-STD-882A, described in the para- 
graphs below: 

When hazards are not eliminated during early design, a risk 
assessment procedure based upon the hazard probability as well as 
hazard severity, may be required to establish priorities for 
corrective action and resolution of identified hazards. 

Hazard severity categories are defined to provide a qualitative 
measure of the worst potential consequences resulting from person- 
nel error, environmental conditions, design inadequacies, pro- 
cedural deficiencies, system, subsystem or component failure or 
malfunction .... 

The probability that a hazard will occur during the planned life 
expectancy of the system can be described in potential occurrences 
per unit of time, events, population, items, or activity .... 

A qualitative hazard probability may be derived from research, 
analysis, and evaluation of historical safety data from similar 
systems. 

Hazard categories I through IV as discussed in Section 2.4.1, were used to 
detennine severity. Use of this technique and subsequent elimination or 
control of Categories I and II hazards were imposed as requirements. 

Rigorous quantitative evaluations of probability were employed only where 
precise, pertinent data were readily available or could be derived and v^ere 
a real need existed for such precision, as in determination of rotor shaft 
safe life. Qualitative evaluations determined whether the hazard was likely 
or unlikely to result in an accident or unplanned event during the useful 
life of the aircraft. An example taken from RSRA experience was the 
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inadvertent actuation of the EES seat barostat during installation. Evalua- 
tion determined that the event was a "one time" failure that could not be 
isolated to a cause. Corrective actions were, however, taken to resolve all 
of several postulated causes, even though the consequences of the actuation 
were not likely to be critical. This over response approach is not uncommon 
where pyrotechnic devices are Involved. 

The approach for hazard resolution was also based upon MIL-STD-882A: 

Action shall be taken to eliminate or minimize hazards revealed by 
analyses or related engineering efforts. Catastrophic and 
critical hazards shall be eliminated or controlled. If these 
hazards cannot be eliminated or controlled to an acceptable level, 
the alternative controls and recommendations will be immediately 
presented to the managing activity. 

When an identified hazard impacted safety criteria satisfaction, resolution 
was accomplished in accordance with the Hazard Reduction Precedence 
Sequence . 


a. Design for minimum hazard. 

b. Employ safety devices. 

c. Employ warning devices. 

d. Implement procedures and training. 

The above sequence of hazard reduction methods is given in descending order 
of safety priority; but, again, the choice was made within the objectives of 
the project as a management trade consistent with resource and performance 
goals. Safety was compromised "vertically" in the sequence only as perform- 
ance or resource limitations dictated. Full evaluation of each option of 
the reduction sequence sometimes resulted in a decision to accept the risk. 

Throughout the process, the RSRA project manager maintained the required 
balance among performance, resources, and safety factors. He applied the 
Hazard Reduction Precedence Sequence while maintaining a clear view of the 
requirements to be satisfied. If the hazard could be eliminated through 
design, while maintaining the balance among the three controlling factors, 
the design change was implemented. Category I hazards that could not be 
eliminated through design required the application of the "safe life" con- 
cept. The design of the main rotor shaft provides an example. Statisti- 
cally representative samples were tested to predict the safe useful life of 
the shafts based on the concept that catastrophic failure modes existed and 
had finite probabilities. The predicted useful life was derated, and main- 
tenance and inspection intervals were specified to ensure changeout before 
critical failure could occur. Another example of this concept, where "safe 
life" was less predictable, was the development of the contractor's 
(Sikorsky) Blade Inspection Method {BIM)^ This technique allowed pressuri- 
zation of the rotor blade spars and detection of any subsequent loss of 
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pressure which would be indicative of incipient catastrophic structural 
failure. This precaution enabled acceptance of an unavoidable single point 
f ai 1 ure cond i ti on . 


Category II hazards which could not be eliminated through design were con- 
trolled through the use of redundancy. Design of the main rotor load 
measurement system, through which the main rotor and transmission are con- 
nected to the fuselage, is an example. Measurement system accuracy require- 
ments could best be achieved by the use of three load cells. However, 
safety considerations dictated the use of as many load cells as possible to 
preclude structural failure. Each additional load cell (beyond three) 
decreased measurement accuracy and fewer load cells decreased safety. The 
final design employed four load cells resulting in fail-safe measurement 
system design, satisfying both performance and safety requirements. 

In some cases, fail-safe design was not sufficient. Such a situation arose 
on the RSRA project when a stability problem required operation of the 
Stability Augmentation System (SAS) to ensure safety. Because of its criti- 
cality, it was apparent that a very detailed reliability analysis was 
needed. Unfortunately, the contractor was not required to perform this type 
of analysis and the Government team lacked the required staff. On the plus 
side, a qualified analyst, engaged in another program, was available for the 
short time necessary to accomplish the study, and another "horse trade" got 
the job done. The analysis concluded that the SAS design had to be dual 
redundant, to tolerate two failures and still be operational (fail-op/fail- 
op). The addition of the SAS redundancy greatly impacted cost, but the 

required degree of safety could not be obtained without it. 

Although many hazards can be resolved through design changes, those solu- 
tions must be evaluated in terms of performance and resource cost. This 
evaluation may drive the solution lower in the Hazard Reduction Precedence 
Sequence scale or direct the acceptance of some risk. The RSRA escape 
system provides an illustration. Ejection at the higher flight envelope 
speeds was found to be clearly unsafe. The evaluation revealed an unaccept- 
able potential for loss of life of the flightcrew. The resolution decision 
weighed whether or not to extensively delay the program and overrun costs 
while the escape system was redesigned. Both performance and resources 
would be severely impacted by proposed redesigns. No feasible way of erect- 
ing barriers around the crew or raising their damage thresholds was con- 
ceived. Qualification testing had demonstrated that the emergency escape 
envelope was less than the aircraft flight envelope. However, precedent for 
this problem had been established on the F-111 program. 

RSRA project management carried the issue to a third party "jury" of 
experts shown in Figure 3.2-2. The decision was made to accept the situa- 
tion under specific conditions. First, only limited operation would be 

allowed beyond the safe ejection envelope. Second, a preflight briefing 
would be held to heighten hazard awareness whenever the escape envelope was 
to be exceeded. Third, the preflight briefing would include a review of the 
proper recovery procedures; i.e., return to the "safe" envelope. Fourth, 
recovery procedure training would be accomplished through simulation to 
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ensure proper pilot reaction (it was a natural response). The hazard re- 
mained, but its LIKELIHOOD was minimized by controlling the flight envelope. 
During limited excursions beyond the safe operating boundary, WARNING, 
TRAINING, and ESCAPE were counted upon. The risk was identified and 
evaluated, and a mutually acceptable resolution implemented. 

These experiences from the RSRA project demonstrate that problems 
encountered in an aircraft development program can be resolved through sound 
management practices. As a final note, it is sometimes impossible to avoid 
risks and still retain a viable project. Incorporation of the previously 
discussed EES is just such an example. The EES serves no useful project 
function, other than to save the crew if a catastrophic event should occur. 
It exists only because the project exists and includes, as does any flight 
project, certain risks. 

For future programs it would be valuable to have a systemati c/ disci pi ined 
approach to hazard evaluation and resolution either outlined or referenced 
in the plan. NHB 17(X),1 (V3), System Safety, and MIL-STD-882A, Military 
Standard System Safety Program Requirements, are excellent references. 
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5.0 CONTROLLING. The RSRA project control activities were used primarily 
to verify compliance with the plan and were in essence an ongoing audit. 
Variances from the plan did occur. Some were anticipated, some were not. 
All were responded to and subsequent planning was adjusted accordingly. 

5.1 CHECKING PROGRESS. Controlling the safety aspects of the RSRA project 
was a matter of maintaining an awareness of current status and taking 
appropriate action. The schedule established in the AQP identified periodic 
reviews for assessment of progress. These reviews (except for the obvious 
safety implications of the RR) were rarely separate safety reviews. As in 
every project, reviews were scheduled — PDR's, CDR's, FRR's, etc. By the 
addition of safety as a standard agenda item, performance, resources, and 
safety status of all elements were assessed interactively at the same meet- 
ing. Data flow associated with a typical RSRA project milestone review was 
shown in Figure 3.1-10. Safety activities were integrated into the main- 
stream of RSRA project development by their inclusion as agenda items in 
formal reviews, as illustrated in Figure 5.1-1. 


1. RESEARCH CAPABILITY (SEE FIGURE 3) 

2. SYSTEM /SUBSYSTEM DEFINITION 

3. PERFORMANCE REQUIREMENTS 
LOADS/STRENCTH 

5. MATERIALS. PARTS, PROCESSES 
i. INTERFACE (INTEGRATION) REQUIREMENTS 

7. SAFETY 

8. RELIABILITY/MAINTAINABILITY 

9. HUMAN FACTORS 

10. QUALITY ASSURANCE PROVISIONS 

- AIRWORTHINESS QUALIFICATION REQUIREMENTS 

- DESIGN ANALYSIS REQUIREMENTS 

- INSPECTION REQUIREMENTS 

- TEST AND MEASUREMENT REQUIREMENTS AND PLANS 

12. DRAWING RELEASE SCHEDULE (INCLUDING SUBCONTRACTOR), RELATED 
TO PROCUREMENT/FABRICATION PLANS 

13. RESOURCES: 

- COST /SCHEDULE STATUS AND PROJECTIONS (BCWS, BCWP, ACWP, 
CVAR. EAC) 

- BASIC DATA ENGINEERING HOURS (BCWP, BCWS, ACWP, SVAR, CVAR) 

- REASONS FOR C/SVAR, PROJECTED IMPACT, WORK-AROUND PLANS 

- STATUS OF POST-PRELIMINARY DESIGN WORK 

- PROCUREMENT STATUS AND PLANS 
U. SCREEN AND ASSIGN ACTION ITEMS 


Figure 5.1-1 Typical RSRA Review Agenda 
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In addition to the design and flight readiness reviews, RSRA project safety 
reviews were conducted when special safety emphasis was required. These 
were reviews of the hazard analysis methods and results, as well as the 
resolution of identified hazards. Examples of items considered at these 
reviews are shown in Figures 5.1-2 and 5.1-3. 


NASA/ARMY ROTOR SYSTEMS RESEARCH AIRCRAFT (RSRA) 

SAFETY REVIEW BRIEFING 

I - DESIGN , (C) HAZARD ANALYSES-FMEA-CRITICAL ITEM CONTROL 

CRITICAL ITEMS IDENTIFIED BY HA/FMEA, DESICN/TEST REVIEWS, FLIGHT SAFETY 
REVIEWS, ETC. 

• SCOPE OF HA/FMEA TAILORED (FLIGHT CONTROLS, LOAD CELLS, AIBS, EES) 
(60 SUMMARY ITEMS) 

• OVERBEY SAFETY REVIEW PLAN (400 ITEMS) (47) 

• EXTRA-ORDINARY SAFETY RELIABILITY ANALYSIS OF (FAIL OP)^ SAS 

• EFCS SNEAK CIRCUIT ANALYSIS NOT IMPLEMENTED (COST AVOIDANCE) 


Figure 5.1-2 RSRA Hazard Analysis Results Review Example 


NASA/ARMY ROTOR SYSTEMS RESEARCH AIRCRAFT (RSRA) 
SAFETY REVIEW BRIEFING 

HAZARD ANALYSES-FMEA-CRITICAL ITEM CONTROL 


• EVERY CAT I OR II FAILURE MODE RESOLVED (49) 

• DESIGN CHANGE TO DOWNGRADE CRITICALITY 

• ANALYSIS/TEST TO VERIFY REMOTE PROBABILITY (SAFE LIFE) 

• INSPECTION REQUIREMENT TO DETECT (FAIL SAFE) 

• PREFLICHT PROCEDURES TO VERIFY INTEGRITY 

• CAUTION/WARNINC PROVISIONS AND EMERGENCY PROCEDURES TO CONTROL 

• CRITICAL COMPONENTS SERIALIZED AND TRACKED IN A/C LOG 

• CUMULATIVE FATIGUE DAMAGE TRACKED FOR EVERY E^ EXCEEDANCE 

• OPERATIONS GROUND/FLIGHT CREW AND TEST TEAM FAMILIARIZED DURING 
DEVELOPMENT 

• DOCUMENTATION WILL PASS WITH AIRCRAFT TO OPERATIONS TEAM 


Figure 5.1-3 RSRA Hazard Resolution Review Example 
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Reviews of this type enabled RSRA project management to redirect the safety 
efforts v#ien required. The redirection of the FMEA efforts toward FMECA's 
resulted from this type of review. While formal reviews were excellent 
places to measure progress, everything was not left until the next formal 
review. An open door policy was maintained to resolve difficulties before 
they grew into major problems. Impromptu meetings were called v^en problems 
arose. Independent inspection teams provided valuable checkpoints on 
project safety. 

The preflight safety inspection of the RSRA provides an illustration. The 
contractor completed the preflight safety inspection, primarily by certified 
Quality Control inspectors, who were properly concerned with conformance of 
the hardware to drawings and to safety practices such as safety wiring of 
connectors. The Government safety inspection team, without reference to 
drawings, looked for hazards inherent in the as-configured aircraft. They, 
not surprisingly, came up with two pages of safety concerns, which were 
subsequently closed out by corrective actions. 

Documentation was used to control the safety program. The requirement that 
all safety efforts be documented provided a means of tracking all issues to 
their resolution. RSRA project management added an appendix to the AQP, as 
discussed earlier, which listed every request for action that resulted from 
major reviews, as well as concerns raised at informal reviews, staff meet- 
ings, or in casual conversations. Included in the listing was a notation of 
action taken, responsible person or organization, start date and completion 
date. A quick look at this report provided status in terms of issues 
identified, those resolved, and those remaining open. 


5.2 IDENTIFYING VARIANCES. Progression through the phases of a development 
project results in variances from the original plan. While some of these 
variances are intentional, others are not. It is important to recognize 
them and assess their impact. 

Waivers and deviations improperly handled can be the nemesis of any program. 
The problem becomes manifest when the pressure gets too great, and people 
tend to look for shortcuts. This situation may be evidenced by request for 
waivers, or qualification by similarity. This type of request should be 
noted as a possible danger signal. People tend to make “gut feel" trades 
between safety resources and/or schedule when the pressure is on. The RSRA 
probably accepted too many instances vhere the hardware was similar but the 
applications were not. A substantial workaround recovery mode was required 
at significant cost and schedule penalty to overcome the risks that resulted 
from accepting the similarity argiment too easily. Waivers and deviations 
on the RSRA were handled by close coordination between contractor project 
engineers, the contractor's "third party" review (e.g., QC or Safety 
Committee), and the Government. Disposition of proposed waivers was handled 
at the project office level but with the advice and consent of third party 
reviewers. Such was the case when the need to waive the RSRA requirement 
for an operational EES prior to first flight was identified. This concern 
involved the ability of the crew to escape in the event of an emergency such 
as fire or mid-air collision. The escape system design and the allowable 
flight envelopes relative to desired aircraft performance bounds became 
"project drivers." The concern was identified early and pursued vigorously 
throughout the design, test, and operations; last-minute show stoppers were 
precluded. Through up-to-the-minute status and projections of escape system 
development, the project office was able to conclude that the qualification 
tests could not be completed prior to first flight. Armed with a current 
and detailed assessment of the impact on system safety/ rel iabil ity of 
initial flights without an anned and qualified escape system, the project 
office was able to perform a credible cost/safety tradeoff in favor of cost, 
and to obtain concurrence by the Executive Safety Conmittee to waive the 
requirement for an operable escape system for initial flight. The RSRA risk 
management approach of early problem recognition and resolution provided a 
solution balanced among resources, performance, and safety. 

5.2.1 Providing Flexibility . The practical view of the RSRA project 

management resulted in an AQP which provided flexibility. The plan was used 
as a daily working document, and progress was reported relative to it. 
Issues pertinent to the plan were discussed in regular staff meetings, and 
the plan was updated subsequent to its initial release in accordance with 
the preplanned schedule and to accommodate significant project changes, as 
shown in Figure 5.2-1. 


61 




Figure 5.2-1 RSRA Airworthiness Qualification Plan Revision Page 


There were a number of project events which precipitated changes in the 
physical plan itself, the areas of emphasis, or implementation of the plan. 
The impact of change is discussed in Section 6.0 of this document. It is 
briefly touched upon here to illustrate the need for flexibility in plan- 
ning. Project changes can take many forms: 

Personnel transfers . The project manager was replaced by the 
chief engineer, who subsequently filled both slots. Flexibility 
was inherent in the project staff. The project was already under- 
way, the promotion came from within, and the chief engineer was 
exceptionally well qualified. 
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Project relocation . The RSRA project was relocated from Langley 

to Ames. Loss of corporate memory and changes in contractor 
support levels resulted. Special training and' increased travel 
were imposed. Although these requirements were not anticipated in 
the planning, they were met through the adaptability of Government 
and contractor personnel . 

Resource reduction . Resources allocated to the RSRA project were 
reduced, resulting in a need for descoping. Cost/performance/ 
safety trades identified areas of least-hurt. This unplanned 
contingency resulted in reduction of safety activity in some areas 
and a schedule slip in at least one other case. 

Schedule slips . PDR and CDR schedules were slipped as a result of 
project technical problems. The taxi-meter effect was minimized 
through the use of the incremental review concept. At least one 
safety issue arose, however, as a result of the unexpected delay 
which is discussed more fully in Section 6.0. 

Each of these conditions was experienced at least once during RSRA develop- 
ment. The AQP provided the flexibility to accommodate these conditions in 
most cases. In others, the AQP itself was changed to meet project needs. 
The balance was made up by the adaptability of the project team. The need 
for built-in flexibility and adaptability is an important lesson learned 
which is directly applicable to future developmental aircraft projects. 

5.2.2 Third Party Reviews . The scheduled project reviews served to 
identify variances, and safety -related activities external to the project 
often provided additional opportunities for assessment. During the RSRA 
project, two NASA-wide activities presented this type of target of oppor- 
tunity. One such opportunity to identify variances by a third party was a 
board convened to audit safety practices on major NASA flight projects. The 
other, in September 1978, reviewed hardware failures in NASA projects to 
assess safety implications. This method of problem solving brought to bear 
resources not normally resident within the project. It enabled exploration 
of all avenues and allowed the manager to stay technically on top of his 
project. Another technique used consistently on the RSRA was the "top ten" 
approach as discussed in Section 3.1.4. 

In response to the guidelines provided by the failure review panel, RSRA 
management identified a dozen failures/incidents that were "significant" by 
the panel's definition. An example was: "Failure of a piece of flight type 

hardware to operate properly and safely or to meet specifications relative 
to flight safety requirements which (based on available data) may adversely 
and significantly affect flight safety, program cost, or schedules or 
mission accomplishment." A summary of RSRA "significant" failures/incidents 
is provided in Figure 5.2-2. 
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PAHiURE/INCIDEOT ASSESS-IEJJT PANEL REVIEW 
Ames Research Center - November 8, 1978 

PROPOSED RSRA AGENDA 


Avail. Data Indicates Effect On 


Rallure 

Category 


Failure Ancldent 


I Cost or 
I Schedule 


Ihennal relief plug In alighting gear 1 Yes* 
Mheels functioned, resulting In de- I 
flated tire I 

I 

EES Blade Severance Assembly failed to I Yes* 
function In environmental qualiflca- I 
tlon tests, due to chemical breakdown I 
of detonation charge at 200°P j 

Fll^t data Indicated gross error In I Yes* 
rotor load research measurement system) 

I 

TiKS deployment bag contacted empennage/ Yes* 
tall rotor au^a of aircraft at 209 kts, 
resulting In usable escape ttivelope I 
less than operating envelope i 

( 

Bnergency Escape System seat pendant | Yes* 
cutter failed to function In environ- I 
mental qualification tests, due to I 
"blow by" around o-rlng seal I 

Stress corrosion crack discovered in f Yes* 
auxiliary engine support fittings! 

AIBS Isolators In roll axis exhibited (Possible 
locked-out characteristics below MOO | 
lbs vibratory force I 

I 

Dual wing tilt actuators did not work | Yes* 
in harmony In the stalled system en- I 
vlronnent, resulting In differential | 
loading of the wing I 

I 

Ibll rotor ran out of directional con- 1 No 
;rol authority at 15 kts right sideward 
fll^t and fatigue loads exceed endur-t 
ance limit In hover, due to greater I 
than predicted T.R. blockage by ( 

vertical tail 1 

I 

Longitudinal stick margin at 153 KCAS,I 


Ineutral eg was less than predicted, 

I indicating potential controllability 
Imargln problem at aft eg 

lEES seat barostat functioned during 
installation, resulting In release 
of shoulder harness and seat buckle 
and Initiation of chute deployment 

Ground operation of aux engines 

In crosswind without rotors turning 
caused tall rotor blade to Impact 
flapping stops, damaging TO and re- 
quiring replacement 


I Minor 


Safety) Mission 


I 

No 1 Minor 
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This special review benefited the RSRA project In two ways: (1) Preparation 
for the review required the RSRA project office to review, categorize, and 
assess hardware failures that had occurred during the project; and (2) the 
review Itself focused the combined judgment of the panel members on verifi- 
cation of satisfactory failure and recurrence control. 

The Importance of Implementing recurrence control is exemplified by item 6 

on the review agenda - stress corrosion cracking in TF34 auxiliary engine 

support fittings. Early in the design phase, it was established that 

7075-T6 aluminum was not suitable for use in the aircraft structure. 

Rescheduling caused by other problems resulted in a delay in design of the 
auxiliary 1F34 engine supports. By the time the design effort was resumed, 
the original airframe design team had been virtually disbanded and a new, 
smaller team staffed. The stress corrosion failure in the TF34 fittings was 
found to result from the use of 7075-T6 aluninum. This incident, and the 
other benefits derived on the RSRA project, demonstrate that this type of 
review should be included in future programs. 

Issues, such as this, involving major program impact, were escalated to the 
level required to achieve resolution/approval. An example of this course of 
action involved the question of flying in the helicopter configuration 
without a qualified EES. As discussed earlier in the section, the issue, 
with supporting analyses, was carried forward to a "third party" Aviation 
Safety Committee and the Langley Executive Safety Board for confirmation (or 
redirection) of the recommendation to waive the requirement for an opera- 
tional EES for initial helicopter flights. Approval was granted based upon 
special procedures and operational limitations. 

While the RSRA was being developed, a systematic review method was being 
created at the Naval Postgraduate School under the direction of Mr. Charles 
Overbey. He produced a document which consisted of critical questions 
related to each major functional area. These questions stand in sharp 
contrast to the usual yes-no checklist questions and are typical of the type 
which have been, or should be, asked in design and operation evaluations. 
The technique established in his document was applied to the RSRA by the 
project manager as a target of opportunity. A sample page from the 
resulting report is shown in Figure 5.2-3. 

At least five critical safety issues were identified and subsequently 
resolved through application of this technique. Use of this "what if" 
technique also served to develop the special safety- rel ated skills and 
traits critical to overall project success. As a specific example one EES 
reviewer asked, "What if the rotor blade pyrotechnic separation system does 
not sever all five blades and the crewmembers are extracted through the 
rotating blade?" The initial answer seemed obvious — an interconnect was 
required. A closer look, however, revealed that the complexity of an 
interconnect system actually decreased the probability of survival; but the 
value of asking key questions was established, and a more comprehensive 
analysis resulted. 
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PROJECT: Army/NASA RSRA 


OVERBEY REPORT 22 


1 .0 Emergency 

1.1 Are full scale blade separation tests planned? Do these tests evaluate 
the effect of shrapnel? 

1.2 Do the engineering analyses and test results give reasonable assurance 
that^ shrapnel from the rotor blade cutting action will not pose a threat 
to safety of the crew and will not pose a threat to integrity of vital 
aircraft systems? 

1.3 Will the short rigid line attached to the blade severence assembly be 
thrown free and possibly strike a vital part of the aircraft? 

1.4 Do planned test satisfactorily cover the expected aircraft airspeed range 
for initiation of blade severance? 

1-5 Do these tests cover severed blade clearance of the tail of the aircraft? 

1.6 Are there any conditions of uncontrolled flight (rolling, pitching yawing. 
Inverted, etc.) where the {ettisoned blades can strike the aircraft? If so, 
have they been evaluated to assure minimum risk for crew bail-out? 

1.7 Has the blade separation rotary transfer unit, which was designed especially 
for this aircraft, been thoroughly qualified by analysis and test? 

1.8 Are the pyrotechnic lines Interna! to the rotor drive shaft supported 
In a satisfactory manner? 

1.9 The flexible lines which connect across the blade hinge are subject to 
constant flexing with each revolution of the rotor. They are also exposed 
to buffeting and vibration. Are these flexible lines of such material and 
size, and are they so supported, as to minimize adverse effects of constant 
flexing, vibration and buffeting? 

1.10 What would be the expected effect of failure of one of these ten (10) 
flexible lines in normal operations? Would such failure create a serious 
hazard? If so, should these lines be periodically inspected and/or replaced 
on an empirical basis? 


Figure 5.2-3 RSRA Overbey Report Example 
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5.3 IMPLEMENTING MODIFICATIONS. Failures and/or incidents occasionally 
necessitated hardware or programmatic changes. Decisions regarding those 
modifications were based on assessment of impact on cost, schedule, safety 
and the mission. A driver in every case was the need to maintain or improve 
the desired level of safety. 

As discussed earlier, the FMEA‘s were used to provide subsystem and system 
hazard identification. This was not an ideal solution, but was the best 
that could be done under the circumstances, and it illustrates the type of 
tradeoffs that may be required to recover from unforeseen problems. 

Another example of task realignment employed by RSRA management early in the 
project was to shift effort from less critical to more critical areas. One 
case involved fatigue substantiation. The original RSRA specifications 
required the performance of fatigue analysis; however, cost of the analysis 
exceeded the project budget. In the ensuing efforts by the Government to 
align the cost and budget, the specification for fatigue analysis was 
changed. The contractor's interpretation of the revised specification was 
to substantiate fatigue by static loads. This type of analysis is not very 
meaningful for helicopters, particularly for the RSRA which is subject to 
fatigue not just in the rotor system but also in the airframe, because of 
the unique configuration of the measurement systems. From a safety point of 
view, this situation was unacceptable, and the RSRA Chief Engineer shifted 
some assignments to obtain a gross fatigue analysis. Man-hours allotted for 
weight and balance tracking and for load analysis were traded to perform 
this effort. The effort expended on weight and balance tracking was held to 
an absolute minimun and the load analysis was performed largely by the 
Government rather than by the contractor. 

Deletion of the fatigue analysis will probably plague the RSRA project for 
the operational life of the aircraft. Operations will be kept safe, but at 
the substantial price of delays to the flight research program. 

Concern over delays to the program resulting from inadequate fatigue 
analyses manifested themselves early in research operation. ITie compound 
version of the RSRA has, in fact, been grounded for substantial periods 
because of unexpectedly high fatigue loads in the horizontal stabilizer. 

5.4 DOCUMENTING HAZARDS. A closed-loop hazard tracking system was 
established in which status of all identified hazards was recorded and 
tracked. The RSRA program accomplished this by the addition of an appendix 
to the AQP called the AQR. The AQR provided a complete listing of all 
concerns identified during the RSRA project and the required resolution 
action. Figure 5.4-1 is an excerpt from the AQP which describes the format 
and content of the report. 
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Risks or concems for airworthiness of the RSRA shall be identified, 
actions required to resolve these concems shall be established and scheduled, 
and a sumary of resolution actions required or taken shall be presented 
in this AQR. The sumary listings shall be included in the agenda of major 
program reviews. 

Table II provides a master listing of airworthiness concems identified 
during the program, along with detailed actions required to resolve these 
concems. The origin of the concern is also identified to provide a visible 
audit trail. 

Table III presents a resorting of Table II actions hy major program review 
milestones and provides airvorthiness agenda items for each program review. 
Follmdng each program review, any open items from Table III or any new 
actions generated from the review will be carried forward to future reviews 
in Table III. Table III agenda iteau from completed reviews trill be deleted 
since they are retained in Table II. 

In order to fiilly docuaent and date specific actiois taken to close 
out AQP items, Suiraary Lists I -XI will be used. Tlie Sumary Lists will 
also be used by the Project Office to continually track action status between 
major reviews. These lists are oriented on s]>ecific events throughout the 
program, to include Table III reviews, plus any other significant activity 
identified. Upon conpletion, they provide a confirehEnsive index of close- 
out docunentaticn. They will be used as a final checklist to insure 
completion of required actions prior to the event specified and will become 
a permanent -part of this AQR when conpleted. 


Figure 5.4-1 Excerpt from the Airworthiness Qualification Report 


Table II of the AQR provided a complete list of all concerns identified 
during the RSRA project. The table identified the subsystem to which the 
concern was related, a brief statement of the concern, the actions required 
to resolve the concern, the completion status of the actions, and a 
reference to how the concern was identified and reported. An example of a 
page from this table is presented in Figure 5.4-2. 
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RISK OR OONO-BN 


MWOlifriON (OR /CTIOW 


REn-anNO; 


FLIQTT 

(XtfTROLS 

llE-K 


llE-10 

(llB-5) 

(lU-1) 

(IIL-S) 

(llN-l) 


Concern for structural intcRrity 
and mechanical reliability of 
control system and coa^xaients 
(includii^ jam modes of failure). 


Concern for ground creu safety 
with actuation of drag brake. 


Concern for co 
integratiep.^ 
instaUa^ 
sub»^ 


*1. Review -'Jesign details at COt. 
*2. Review FKEA's prior to ERR. 


Review test plans (Qual. test, acceptance tests 
pre- flight ground tests) prior to tests, and review 
test results prior to FRR 


RPA 7/11/74/VI-ll 

7/11/74-VI-i: 

7/ 11/74 -VI -14 
f 

7/11/74-VI-r- 


*4. Review configuration at first article inspection RFA7/9/76-rRR-ir 
prior to FRR 

*5. Verify flight loads prior to envelope expansion. 


*1. Provide ground safe device; confirm at COR 
(Removable pin) 


RTA 7/11/74-VI-i: 


test and first 
-*<. 5 oinpound test. 


Figure 5.4-2 Example of AQR Table II 


Table III of the AQR listed the concerns that were not resolved prior to a 
project review and were agenda items for that review. Following each 
review, a new sheet was added to Table III to carry forward any open 
concerns for consideration at the next review. 

The AQR also included summary tables of concerns requiring action prior to 
specific project milestones. These tables contained basically the same 
information as shown in Table II, but they also contained a reference to the 
resolution documentation for the concern and the date the resolution was 
effected. An example summary page is presented in Figure 5.4-3. 


9M44RY - ACTION I1B6 

1. Conpletlcn RcqulTod Prior to Restag>ticn of Helo Flights (Flights resuwd 7/13/77) 


Rovisod July 12. 1977 
Final revision 


RISK OR 
OONCSW 

REsourrioN or 

ACTION REQUIRED 

REFERENCE 

CLOSBOin’ REFERENCE 

DATE 

B4I 

Perfoim/verify Hfl tests 

SOFR 9/29/76 
AQPIII-llE-6 

Langley memo to Merrill 
7/7/77, 256/R, Hirray 

7/7/77 

Riel System 

Perform/verify fuel 
system calibration and ATP 

SOFR 9/29/76 

RSRA Memo to Files, 
246E/SMhite:bpj 

6/23/76 

EPOS 

Perfoim/verify EPOS 
ground tests 

SfVFR 0/29/76 

Langley Memo to Merrill 
7/7/77, 2S6/R. HuiYay 

7/7/77 

Proof opera- 
tional r •— 

^ Pr-* — ' — iff 

SOFR 9/29/76 

Sikorsky ETR per J. Brllla 




Figure 5.4-3 Example of AQR Summary Table 
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The technique employed by the RSRA project for docunenting hazard resolution 
was excellent. It provided for a complete listing of all identified hazards 
and a record of the resolution action implemented. Thus, any hazard or 
concern could be traced from identification through verification of 
resolution. 

The RSRA experience has demonstrated some basic truths related to hazard 
doc mentation which can be applied to future projects. A record should be 
maintained of all concerns and not just those considered significant. 
Resolution action should be verified before the issue is closed. This 
leaves a clear audit trail. Years later it may become necessary to 
reconstruct the actions taken and rationale for decisions made. Finally, 
allowance should be made for updating the docmentation as warranted by 
additional knowledge and time. This flexibility is essential in maintaining 
a viable docment consistent with realistic needs of developmental projects. 
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6.0 ADAPTING . A host of ills can beset the manager after the project is 
well underway and (he thought) under control. Programmatic changes beyond 
control of the manager can be devastating. If not properly handled, chaos 
will result. Potentially disruptive changes occurred on the RSRA project 
with some regularity, but built-in adaptability ensured positive project 
direction and control. 

The AQP established milestones for completion of each program phase. How- 
ever, some events beyond management control resulted in schedule slippage, 
but not in loss of project control. Flexibility was the key. The ability 
to adjust schedules because of safety considerations and without further 
compromising safety was essential . The night before the PDR, an aerodynamic 
instability problem was revealed by wind tunnel testing. The resolution of 
the problem required redesign of the tail. Obviously, that section of the 
aircraft was not ready for even preliminary design review. It was decided, 
however, to proceed with the design review of the aircraft, with the excep- 
tion of the tail and the auxiliary engine mounts which would probably change 
to offset the center of gravity shifts which would result from tail rede- 
sign. A delta PDR was held after redesign of the tail to ensure that system 
safety and performance had not been compromised. The decision resulted in a 
6-month project slip to ensure safety. As a part of the delta PDR, results 
of the previous segments of the review were re-evaluated to ensure their 
currency and continued validity. That's an important thing to remember for 
future projects. 

The next major system review, the system CDR, was originally scheduled to 
follow the last of the subsystem CDR's. It was decided, however, because of 
schedule slippage, to conduct the system CDR prior to completion of the 
EFCS, AI/BS, and EES subsystem CDR's. Workaround plans were prepared to 
accommodate installation of the affected systems after first flight of the 
helicopter to minimize the impact on overall project schedules. The 
resulting schedule for the CDR's is shown in Figure 6.0-1 below. 


WBS 

SYSTEM 

CDR DATE 


11A 

AIR FRAME 

JUNE 10, 1975 (final) 


11B 

SECONDARY POWER 

JANUARY 8,1976 


nc 

PRIMARY POWER 

MAY 7, 1975 


11D 

LIFE SUPPORT /ENVIRONMENTAL 

MAY 7, 1975 


11E 

FLIGHT CONTROLS 

JANUARY 8. 1976 


11F 

DRIVE 

FEBRUARY 6. 1975 


lie 

ROTOR 

FEBRUARY 6, 1975 


IIH 

ENGINES 

MAY 7, 1975 


11J 

AVIONICS 

FEBRUARY 6. 1975 


11K 

EMERGENCY ESCAPE 

FEBRUARY 6, 1976 



- STATUS REVIEWS 

- FINAL CDR 

(HOLLOMAN TEST READINESS) 

- POST HOLLOMAN TEST 
REVIEW 

- QUALIFICATION REVIEW 

JUNE 10 AND NOV. 11, 
JAN. 30 AND FEB. 11, 
AUGUST 6, 1976 

APRIL 14. 1977 

JUNE 16, 1977 

1975 

1976 

11L 

ONBOARD RESEARCH INSTRUMEN- 
TATION 

MAY 7. 1977 


11M 

ACTIVE ISOLATOR /BALANCE SYSTEM 

- STATUS REVIEW JANUARY 22. 1975 

- FINAL CDR JULY 1, 1976 


11 

SYSTEM 

(RECONFIRMED AFTER 11E) 

JULY 1, 1976 



Figure 6.0-1 RSRA Incremented CDR Schedule 
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As shown by this example, the plan evolved with the project. This flexible 
approach enabled project management to stay abreast of the changing nature 
of hazards as the design, development, and test phases of the project were 
accompl ished. 

Again, as with the PDR, it was necessary to re-evaluate total system pos- 
ture after completion of the delta reviews. Stress corrosion cracking of 
the engine support fittings, described in Section 5.2.2, resulted from use 
of a prohibited material, which was a configuration control problem. Slack 
time during the CDR slippage probably fostered some laxity which allowed the 
problem to happen. That was a review discipline problem. 

Ten months after initiation of RSRA flight tests at the contractor's plant, 
the flight test operations were transferred to NASA -Wallops Flight Center 
(WFC) with the intent of phasing over from contractor to Government flight 
operations by Langley at WFC. In mid-stream, NASA transferred the heli- 
copter roles and missions from Langley to Ames. As a result, a year and a 
half after starting operations at WFC, one of the two aircraft had to be 
transferred to Ames Research Center for continuation of its flight testing. 
One year after that, the other aircraft was also transferred to Ames for 
completion of development flight testing and for research flight operations. 

During the first of these site relocations, there was a transition from 
operations at the contractor plant (fully supported not only by the project 
team, but by the aggregate of all of the contractor's support personnel and 
facilities) to remote site operations by a small contractor team supported 
by a different Government-operated flight facility. During the transfer 
from WFC to Ames, in addition to the change in flight facility, there was a 
transition from operation by a contractor team monitored by a Government 
team, to operation by the Government team supported by a contractor team. 
These difficulties were compounded by lack of travel funds to permit con- 
tinuity of Government team participation, as well as by periodic rotation of 
contractor personnel from the remote site back "home." 

These changes in site and transition between contractor and Government teams 
resulted in a partial loss of corporate memory. This loss was compounded by 
a decision early in the program to adopt the experimental shop approach to 
documentation for reasons of cost. A complete set of preliminary drawings 
and changes (but not final drawings) was eventually forwarded to Ames. The 
results of these changes and early decisions have not degraded the safety of 
the RSRA, but have made the maintenance of the desired degree of safety more 
difficult. 

Transition from the project development phase to the operational phase is 
normal, but it is not without its own special problems. Probably the single 
most difficult problem deals with corporate memory loss as discussed above. 
The problem is compounded on R&D, one-of-a-kind projects, because tradi- 
tional "fleet" documentation is usually not prepared. New people are 
unfamiliar with development problems, and there are no established training 
programs. 

Key operations- type personnel (just like safety) should be integrated into 
the development project early. Such an interlocking arrangement will mini- 
mize transition problems and enable an on-schedule release for flight as 
shown in Figure 6.0-2. 
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r.JCiOnai Ae''or'a-:.;s and 
Space ACmirrsfration 

Langley Research Center 

harrpizr V.fzn.a 
23535 


lUASA 


SEP < • 


Sikorsky Aircraft Division 
(kiited Technologies Corporation 
Attn: ^!r. Merrick W. Hellyar 

Stratford, CT 06602 


Subject: Safety- of -Flight Release, Contract NASl-13000, RSRA 


Based on the results of the final safety-of- flight review at the 
S^tenlber 28, 1976 Pre- Flight Revietf, authoriration is granted for 
release of the RSRA for flight tests, with the following conditions 
and limitations; 

1. Configuration. - This Safety-of- Flight 

the RSRA Hal 1 . ^ 

Escape discrepancies for aircraft 

This Safety- of -Flight release is further conditional upon satisfactory 
conpletion and resolution of the following open itans from the Pre- 
Flight Revieitf of September 23, 1976: 

1. Prior to flight with SAS 1 and 2 actuators: 

a. Substantiate structural integrity for \»lbration/fatigue 
and revalidate qualification status. 

b. Measure SAS actuator motion to verify summing and verify 
acceptability of hardovers. 

c. Verify collectii»-^j;2-J--^ ^ 

2, checks. 

to installation of load limiter shear pin, verify 
integrity for limit load. 

6. Prior to performance to monthly periodic inspection (due 
October 31, 1976) verify EFCS monthly inspection procedure, 

I ETP 72T2- 00004. 


Donald P. Hearth 
Director 


Figure 6.0-2 Conscientious Application of Safety Principles by Dedicated and 
Technically Superior Project Teams Leads to Release for Flight 
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CONCLUDING REMARKS 


This document has provided insight into establishing and implementing a 
safety program for developmental aircraft projects. It has demonstrated, 
through examples, the approach taken by the RSRA project management. Though 
not always in accordance with the classical approach to system safety, this 
method was effective and successful. This success is a direct result of 
planning, organizing, directing, and controlling the project with the proper 
degree of emphasis on safety. 

A specific conclusion to this document, covering more than 6 years of RSRA 
history, is perhaps best supplied by the former RSRA Project Manager/Chief 
Engineer, Sam White: 

0 Apply the basic principles of management, especially those 
that fall into the category of safety tasks. The safety tasks 
are finite and do- able and, properly done, they'll reduce 
ri sks . 

0 Plan the safety activities (who, what, when). Use whatever 
specs, standards, or regulations you want, but use an authori- 
tative requirements document and tailor it to fit the project. 

0 Not only plan the work, but also work the plan. Track it with 
fairly rigorous discipline and document the audit trail, 
paying attention to details. This takes work, but it not only 
prevents dropping something down the crack and provides "CYA" 
paper, it also creates an attitude and awareness that safety 
is real and really beneficial to the project, not just a 
burden . 

0 Assign a competent chief engineer who is clearly accountable 
not only for safety but also for mission/ system performance. 
Permit (encourage!) him to take an adversary role viz the 
Project Manager on cost/ schedule versus safety tradeoffs. 

Don't delegate the tough problems. 

0 Use the jury concept in project reviews and in making 
conscious decisions to accept risks. Make sure "calculated 
risks" are truly calculated . 

0 Use the top ten approach. Start with the ten highest tech- 
nical risk areas and list all actions to be taken to resolve 
them. As real problems emerge, establish top ten problem 
actions. Go down alternative or contingency paths in parallel 
with best solution path; don't wait to do it in series with a 
"no go" on the best path. In other words, tend to overkill 
top ten problems. 

0 If you are faced with a resource- impacting event -- such as a 
funding cut -- you will want to consider waivers, qualifica- 
tion by similarity, descoping, reassignment of duties, and 
possibly an "experimental shop" approach. Any of these 
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methods can be employed with success. However, the experi- 
mental shop approach is not recommended due to the loss of 
controllability. If you choose to waive requirements, be sure 
to make deliberate, informed decisions — not default deci- 
sions. Likewise, in using shortcuts — such as qualification 
by similarity — verify that similarity really exists in all 
pertinent areas: Environment, use, life cycle, etc. The 

point is, consider the safety aspects in making your manage- 
ment decisions. 

o Communicate problems to "management." Present options and 
your recommendations ("cancel the program" is an option that 
needs to be addressed, even if you don't recommend it). Do 
this early enough , when the options still exist; don't delay 
to the point of forcing the default option. 

In addition to Mr. White's synopsis of RSRA experience, a more generalized 
conclusion in retrospect is provided. The approach taken by RSRA manage- 
ment in planning the safety program was to integrate the safety goals into 
the pro.iect goals. This approach was initiated by incorporating safety 
requirements into the AQP. This deviated from the more standard approach of 
providng a separate safety plan by providing a single document for project 
guidance with emphasis on safety as well as performance. The ultimate use 
of the aircraft to be developed was considered in the definition of all 
program requirements. 

Requirements tailored to the specific needs of the RSRA project carried 
through the organizations of the work as well. "Horse-trading" of resources 
was performed to apply project emphasis in the most critical of areas. 
Actions such as these trades, effected by project management, are definitely 
a deviation from the more standard approach which tends to satisfy contract 
requirements regardless of project need. Contract requirements were satis- 
fied on the RSRA project, but through these "horse-trades" the emphasis of 
the project was shifted, when necessary, toward safety. Another deviation 
from the more conventional organization was the lack of a separate safety 
staff. The RSRA project management established a safety focal point sup- 
ported by the subsystem managers. This emphasized safety as an integral 
part of project success and required that the most knowledgeable and com- 
petent personnel be involved in the safety effort. Even the test pilots 
were involved throughout DDT&E and were integrated into the project "family" 
to promote safety consciousness and inject human factor considerations into 
the design. 

The RSRA attitude toward safety was also significantly influenced by the 
project manager's personal characteristics. His safety-conscious approach 
to project direction was demonstrated by such things as seminars conducted 
to educate the project staff in safety principles. Education of staff 
members is not always included in the approach to system safety, but 
definite benefits were evidenced in the RSRA project. 
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Just as the plan and organization were adapted to the specifics of the RSRA 
project, the safety tools which were applied in the project were selected to 
provide maximum return for resources expended. The decision to apply or 
omit the application of particular safety tools was carefully weighed. In 
some cases, additional tests and procedures were substituted for certain 
analyses. In the long term, these substitutions were not always cost effec- 
tive. For example, application of sneak circuit analysis earlier in the 
project could well have circumvented the need for some extra tests and 
special procedures. Likewise, the performance of a PHA earlier in the 

project than actually perfonned would have provided more useable results. 
On the other hand, the redirection of the FMEA toward assessing criticality 
rather than probability of failures was an excellent example of good safety 
management. 

The application of the safety tools identified safety concerns, as did the 
subsystem and system reviews. The decision to include knowledgeable people 
who were not involved with the project on the review boards was a profitable 
deviation from the normal methods for controlling a project. The perspec- 
tive and insight provided by these third party experts added significantly 
to the safety value of the meetings. Another example of excellent manage- 
ment was seen in applying the Overbey technique to the RSRA. There was no 
requirement for the applications of the technique, and s(3me additional 
effort was required of the project staff. This extra effort identified 
concerns at a point in the project which permitted resolution before serious 
problems arose. 

An innovation by the RSRA project management, the AQR, greatly benefited the 
RSRA project by providing complete documentation of safety concerns. This 
prevented duplication of effort while ensuring that all concerns were 
resolved. In a like manner, the use of the top ten problems concept assured 
that concerns were elevated to the proper levels of management and focused 
the proper attention to the more critical issues. 

Finally, history has shown that the approach of the RSRA project management 
provided adequately for safety. The approach alone did not accomplish this, 
but the commitment of an astute project manager, supported by a dedicated 
staff, resulted in a safe and successful project. Project safety can, 
therefore, be seen as achievable by maintaining a safety-conscious environ- 
ment coupled with a systematic approach to balancing performance, resources, 
and safety at all times. RSRA stands as a witness to the efficacy of these 
techniques for safety. 
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